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I. INTRODUCTION 


А. BACKGROUND 


Many enterprises are still running and maintaining several computerized legacy 
systems that play a significant role in the success of their operations. These legacy 
systems try to handle every possible requirement a developer could conceive. Such 
systems are hard to develop, difficult to maintain, and almost impossible to adapt to 
future needs in a reasonable amount of time. Moreover, the emergence of Web-based 
technology, enhancements in the client/server architectures, the decrease in the price of 
personal computers, and the existence of platform-independent programming languages, 
have opened new ways to do business. These new technologies are considered 
revolutionary compared to what was available just a decade ago. Therefore, many of these 
enterprises are considering a redesign process for their legacy applications to benefit from 
these technological enhancements and to conduct their businesses in a more efficient and 
economical way. 

A single enterprise, depending on the kind of business it provides, may maintain 
several information systems simultaneously. Those systems may run on different 
Operating systems and on multiple platforms. In most cases, those information systems 
are not separate from each other. In fact, they are related; that is, the output of one system 
is often the input used by one or more of the other systems. Enterprises find themselves 
needing to aggregate or extract information from more than one system. The variety in 
platforms and operating systems poses a challenge to system-wide interoperability and 
performance, increases the cost of maintenance, and ties those enterprises to limited 
choices of technology. For example, every time an enterprise wants to procure or develop 
a new computerized system, it must know if and how this new system will interoperate 
with the current legacy systems. Moreover, as a result of being platform dependent, these 
computerized systems usually suffer a lack of adequate information sharing. This results 
in redundant data maintained by different systems and leads to a waste of computer 
resources, manpower, and time. This inadequate information infrastructure also increases 
the potential occurrence of errors and contributes to a lack of data integrity, for example, 


an update is missed or is not performed appropriately. 


В. OBJECTIVES 


One avenue along which to address the challenges mentioned above is to use a 
platform-independent, object-onented application language and a backbone that easily 
connects different applications and databases running on different operating systems. The 
primary objective of this research is to develop an object-oriented web-based Inventory 
Ordering and Tracking System (IOTS) prototype as a proof of concept for our proposed 
first step of implementing interoperability and addressing other shortcomings in the 
current legacy systems. 

Since each enterprise has its own problems, needs, and requirements, there is no 
way to design an IOTS that satisfies the business needs of every possible enterprise. 
Therefore, the IOTS prototype is built for a hypothetical group of warehouses that we are 
going to call the Quick Supply Incorporation (QSI). The QSI is assumed to be running a 
legacy platform and operating system dependent IOTS that takes the responsibility for 
receiving, processing, and tracking customers’ orders. The QSI is looking forward to 
solving the problems of its current legacy system and benefiting from the modern 
technology enhancements. 

The open, object-oriented Web-based client/server, IOTS prototype for the QSI is 
a vehicle for addressing the weaknesses of current legacy systems, the problem of 
interoperability, and the issue of operating system and platform dependence. The 
prototype illustrates how effective solutions, made available by the new technology, can 
be utilized to solve some of the problems of the legacy applications, while demonstrating 
the technical feasibility of such solutions. Enterprises that want to benefit from the new 
technology and replace their platform and operating system dependent applications may 
find this research beneficial. The provided source code for the IOTS prototype can be 
tailored to some specific business requirements. Enterprises, who have similar problems 
to those addressed here, may adopt the development methodology used in this research to 
address their own specific problems. 


In this research, we address the following questions: 


• What are the requirements of the new IOTS database and application 
program for the QSI? 


• What are the possible benefits and advantages of this program from both 
the technical and management perspectives? 


~ 


• What is an appropriate design for the new IOTS database and application 
program? 


• How extensible is the new IOTS in terms of the use of different types of 
databases and different operating system environments? 


С: LIMITATIONS 


The IOTS prototype will be used to highlight this research’s major objectives and 
it will not be very detailed. After we design the new structure and define the multiple user 
interfaces of the proposed IOTS, we pick just one of these interfaces and go through the 
design and implementation processes. In most cases, we skip the minor details in order to 
stay focused on our objectives. We will not handle the data migration from the existing 
legacy system to the new JOTS. The prototype will not track performance measures that 
show how well the system operates. In order for this prototype to have a practical value 
and be ready for deployment, it needs to implement the remaining user interfaces, migrate 
the legacy data, track performance measures, manage security related issues, and pay 


attention to the business rules that were not taken care of. 
D. METHODOLOGY 


Our research passes through the following phases: 


o Requirement Analysis. We start by analyzing the current situation and the 
need for such a database application program. Then, we list the 
requirements of what a modern IOTS should be. The requirements will be 
derived from the best business practices in place today. It will target 
solving the existing problems and will gain benefit from the modem 
technology enhancements. 


• Logical Database Design. We develop a data model using the Semantic 
Object Modeling technique to capture the user requirements, and then we 
transform the data model into a relational database design. 





ө Physical Database Design. We use the Structured Query Language (SQL) 
to build the IOTS’s database schema from the design. The database will be 
loaded with some sample data for testing purposes. The IOTS prototype 
will use its GUIs to populate some parts of the database with data. The 
remaining parts will be populated with sample data using SQL commands. 


These parts are supposed to be populated by some other user interfaces 
that we are not going to design. 


• Application Design and Implementation. We design and build a three- 
tiered database client/server application prototype. The first tier, the client, 


is the user interface that will be running on the Web browsers. The second 
tier, the server, can serve both HITP and CORBA. The server will 
encapsulate the business logic and interact with the client via 
СОЕВАЛОР. CORBA objects will interact with each other using 
CORBA Object Request Broker (ORB) and they will talk to the third tier 
using SQL/JDBC. The third tier consists of the DBMS that will be 
accessed by the CORBA objects. CORBA/Java will be used to encapsulate 
most of the third-tier functions. 


• Analysis and Recommendation. After completing prototype 
implementation, we discuss the benefits, advantages, and costs of adopting 


this program over maintaining the status quo from both a technical and 
management perspective. We also address the issues of interoperability, 
scalability, and portability. The thesis also recommends future work. 


E: ORGANIZATION OF THESIS 


This thesis consists of four parts that build on each other: Part I addresses the 
problem, analyzes the current situation, and lists the requirements for the proposed 
system. Part IJ gives the reader background information required to understand the 
following parts of this research. This part provides an overview of Relational Database 
Management System (RDBMS) and Structured Query Language (SQL), Java and Java 
Database Connectivity (JDBC), and Common Object Request Broker Architecture 
(CORBA). Part III describes the design and the implementation of the IOTS prototype. 
Part IV analyzes the benefits of adopting the IOTS over maintaining the status quo and 


recommends future work. The following is a more detailed outline for each chapter: 


• Chapter I: Introduction. This chapter introduces the problem to be 
addressed, gives a justification and purpose of this work, and lists the 
basic structure of the thesis. 


• Chapter II. Inventory Ordering and Tracking System (IOTS). This chapter 


describes the current system, its problems, and the requirements of a new 
IOTS. 


Chapter Ш. Technological Background. This chapter contains an 
overview of relational databases and SQL, Java and JOBC, and CORBA. 





Chapter IV. IOTS Relational Database Design and Implementation. In this 
chapter, we build a data model using the Semantic Object Modeling 


technique. Next, we transform the semantic data model into a relational 
database design. Finally, we implement the design and generate the 
schema. 


Chapter V. Design and Implementation of the IOTS Web Based 


Application Program Prototype using CORBA and JDBC. In this chapter 
we start by selecting the Object Request Broker (ORB) implementation 


from the available ones by different vendors. Next, we go through the 
application design process using the ORB that we selected. After that, we 
design and implement the prototype. Finally, we list and comment on 
some snap shots of the prototype. 


Chapter VI. Analysis and Conclusions. This chapter analyzes the benefits 
and costs of adopting the IOTS application over maintaining the status 
quo. It will examine to what degree scalability and interoperability are 
achieved. This chapter will also summarize the lessons learned, give 
directions on how to enhance the application prototype, and guide the 
reader to some future related work. 
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П. INVENTORY ORDERING AND TRACKING SYSTEM 


This chapter analyzes the current sıtuation, addresses the problems, and lısts the 
requirements for a proposed solution. In the later chapters, we design and implement a 
prototype of the proposed solution as a proof of concept illuminating the solution’s 
technical feasibility. 

The Quick Supply Incorporation (QSJ) is currently running a legacy IOTS that 
takes care of receiving, processing, and tracking customers’ orders. The IOTS suffers 
mainly from two major categories of problems. The first category consists of the 
problems imposed by the external environment in which the JOTS operates. The latter 
category has to do with the inability of the legacy IOTS to take advantage of more 
efficient ways of doing business generated by the recent advancements in many new 
technologies, such as the Web, client/server architectures, and object-oriented platform- 
independent programming languages. So, a new design for the IOTS needs to address its 
environmental problems, in addition to satisfying its new requirements of benefiting from 


the modem technology enhancements. This chapter consists of the following five 


sections: 
e The structure 
Ф The environment 


Ф The current IOTS 
• The problems with the current IOTS 
Ф What a modem IOTS should be 


A. THE STRUCTURE 


Figure 1 shows the highest-level view of the QSI’s structure that consists of: (n) 
number of warehouses, a Central Management Office (CMO), and (n) number of 
suppliers. The warehouses are spread over different geographical regions and centrally 
managed by the CMO. The CMO also maintains certain levels of inventory in its main 
store. This inventory is made available to fulfill expected customers’ orders. 

The IOTS controls the inventory across these multiple warehouses; each 
warehouse retains local responsibility for inventory management, order processing, and 


order tracking. Tracking at this level is managed by Local Store Managers (LSMs). 


Another level of management ıs performed by Global Store Managers (GSMs) in the 
CMO. The GSMs are granted much more authority than the LSMs. They are able to 
control the inventory levels no matter in which store the inventory exists. Usually, every 
GSM specializes in controlling a specific type or types of inventory. In most cases, LSMs 
must go through GSMs to reach the suppliers since the procurement of most types of 


inventory is a centralized function controlled by GSMs. 


VJ Supplier 1 


Central Management Office 


Warehouse 1% Warehouse 2 Warehouse пу 


Figure 1. The Structure of the QSI 





B. THE ENVIRONMENT 


The IOTS ıs not a closed system operating separately on its own. In fact, it needs 
to communicate with some other systems to achieve the integrity requirement needed for 
the QSI to perform its operations successfully. As shown in Figure 2, the IOTS interacts 
with the Accounting System (ACS), the Personnel System (PERS), and the Management 
Information System (MIS). Although the interaction among these systems is not as 
smooth as desired, the QSI views these subsystems as part of a single overall system 


called the Enterprise Information System (EIS). The EIS is currently running on different 


platforms using different operating systems. The Figure shows the environment in which 
the EIS, including the IOTS, operates: 


- табу» зас е ~ . — Үз. этиу DDR ree E Terug ~ — 
E PI > “ 
E ? x 


Programming | Visual “Basic, Lotus Notes, 
Oracle, MS. Access . 
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Management | | 
Information Systems | Accounting 
се с шш (MIS) | System (ACS) 


Other Office Work | Personal System 
related Systems | (PERS) 


> Operating | 
. Systems Windows 3.1/95/98/ 
NT, Novell 





Figure 2. The IOTS Environment 


The IOTS interacts with two major categories of applications. These categories 
are distinguished by the platforms on which they run. 

The first category consists of the applications that run on the mainframe, such as 
the PERS and the ACS. Those applications are mainly written in COBOL, and they run 
on the top of the UNIX operating system. The interaction between those applications and 
the IOTS goes smoothly most of the time because of the previously mentioned common 
similanties among them. To highlight the importance of this interac'« л, we give two 
examples. First, users of the ACS need to receive highly accurate status and prices from 
the IOTS so they can pay the suppliers. Second, the IOTS must verify all of its users with 
the PERS. In order to be able to track “who did what,” the IOTS keeps a history of all the 
transactions made on any given inventory associated with the identification numbers of 


the authorized personnel who performed those transactions. 


The latter category consists of the applications that run on PC LANs. Those 
applications are written in various programming languages, such as Visual Basic, Lotus 
Notes, Microsoft Access, or Oracle, and they run on different operating systems such as 
Windows 3.1/95/98, or Windows NT. The PC LANs use Novell Netware as their 
communication backbone. Unlike the natural and smooth real-time interaction among 
applications in the first category, the interaction between the applications in this category 
and the IOTS takes place via a batch-processing step. The MIS extracts information from 
the IOTS in order to enable decision-makers to plan for inventory control, annual 


budgeting, and cost analyses. 
2. THE CURRENT IOTS 
1. Analysis 


The current IOTS consists of a set of legacy application programs wnitten in the 
COBOL programming language. The IOTS maintains a centralized database that stores 
information about all the items available for sale. The IOTS runs an application program 
that allows the QSI-authonized personnel to access the information in the centralized 
database, to inquire about inventory levels, to place orders, and to inquire about the status 
of their orders. 

Figure 3 defines the current IOTS system boundary. This figure shows the IOTS 


network layout, and suggests that the IOTS has the following eight major functional 


activities: 

• Order entry. Local warehouses perform this activity. These warehouses 
are responsible for placing, tracking, and filling customer orders. Another 
responsibility of these local warehouses is to maintain certain levels of 
inventory in stock to fill future customers’ orders. 

• Shipping. The responsibility of this activity is to ship ordered items from 
the main store to the local warehouses. In the current system, customers 
are responsible for picking up their orders. 

• Receiving. This activity takes the responsibility of handling the inventory 


received from suppliers and matching it to the backordered requests. 
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• Accounting. Once a stock is received from the suppliers, it is processed by 
the IOTS and the invoice is mailed to the ACS in order to manage the 
supplier's accounts payable. 


• Purchasing. This actıvity ıs responsible for ordering inventory from 
suppliers and tracking the status of the suppliers’ shipments. 


° Stocking. This activity is responsible for both placing newly arrived 
inventory in stock and filling customers’ orders. 


• Planning. This activity uses different statistical reports in order to 
maintain an appropniate level of stock within budget constraints. 


• Decision-making. This activity assists top middle managers perform 
inventory control, annual budgeting, and cost analysis. 


2; Data Flow 


Data flow diagrams (DFDs) are very useful in representing the overall data flows 
into, through, and out of the IOTS. DFDs are hierarchical in nature and can be 
decomposed into smaller, simpler levels. These diagrams are used to facilitate the 
analysis of the logical data flow in the current system, discover discrepancies, and help us 
design the new logıcal system. 

The context diagram of the IOTS, shown in Figure 4, presents the highest-level 
view of the entire system. All DFDs in this research use the DeMarco and Yourdon’s 
symbol conventions that are presented in Appendix B. Basically, the IOTS accepts orders 
from customers and fills these orders. Once there is a need to get additional inventory, the 
IOTS places orders to get that required inventory from its suppliers. The suppliers, in 
turn, ship the ordered inventory with the invoice. The IOTS processes the received 
inventory, matches the received inventory to the invoice, and sends this invoice to the 
ACS in order to manage the accounts payable to the supplier. It is imp "ant to note that 
sending the payment to the suppliers occurs between the ACS and the suppliers, and thus 
is outside the IOTS system. The IOTS makes its inventory levels and some other 


information available to the MIS that uses this information for its own purposes. 


PERS 
Inventory 


Invoice Levels 
Personal Data 


Customer Orders 


On Inventory Supplier 
Customer Ordering and 


Tracking System 
Invoice/ Invoice 


Receipt 





Figure 4. Context Level Diagram for IOTS 


In order to get a more detailed understanding of the functionalities of the IOTS, 
the context diagram can be decomposed further into multiple levels of DFDs. The first 
level of these DFDs is shown in Figures 5, 6, 7, and 8 by grouping the top level processes 


into the following four major categories: 


• Placing queries 
• Processing customers orders locally 
• Processing customers orders by Global Store Managers 
• Отдеппо inventory from the suppliers 
а. Placing Queries 


Placing queries is simply performed by passing requests to the system and 
receiving responses. The IOTS provides many queries that enable the users to do their 
jobs without much strain. Appendix C lists some of these queries. Figure 5 identifies the 


following four major groups of users: 
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Local Store Managers (LSMs) are able to query the system about the 
inventory levels of their warehouses, and they can place and track orders. They perform 
the tracking on behalf of their customers; the customers are informed of their orders’ 
status upon their request. They are also notified when their orders are filled and ready to 
be picked up. LSMs also track the orders they place for stocking purposes. These orders 
aim to make some inventory available in stock for future customer needs. Having 
inventory available in stock will serve the customers without delay, but the inability to 
determine exactly the future needs of the customers and the budget constraints will make 


some of those customers experience various delays before getting their orders filled. 


4-- --- 
Response 


Request 


Local Store 

Manager 
Query Prepare 

Inventory Statistica 
Levels ] Data 


Get 
Global Store Response Statistical 


Manager Data 
Query Query Reply 


Inventory 
IOTS Database Levels Statistical Data 





Figure 5. Placing Queries 


Global Store Managers (GSMs) are given much more authority than 
LSMs. The GSMs are able to control the inventory levels no matter in which store this 
inventory exists. Usually, every manager specializes in controlling a specific type or types 
of inventory. 

MIS users, either strategic or middle managers, receive statistical data 
from the IOTS for inventory control, annual budgeting, and cost analysis purposes. 


Customers perform queries about their orders via the LSMs. 
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b. Processing Customers’ Orders Locally 


The LSM places the order on behalf of the customer, venfies that the order 


has all the necessary information, inquires about the inventory level, and proceeds further 


in processing the order. The ordered inventory may be available at the local warehouse, 


partially available, backordered, or not available at all. Figure 6 shows how the 


customer’s order is processed locally: 


Customer 


Order 
еее. саты! 
әмер 


R 5 Review 
Order Order 


Reviewed |Order 


Canceled Order 


Process 
customer 
Order Locally 


Order with 
Unavailabld Stock 


Order with 


Availabl tock 


Generate 
Inventory 
Decrements 


Process 
Orders with 
Unavailable 

Stock 


Inventory Data 


Receive and 





IOTS Database 


Inventory 
Levels 


rack 
Number 


Customer 


Figure 6. Processing Customer Order Locally 
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+ If the inventory is available the order might be filled in full, or 
partially filled. 


• If the inventory is not available the LSM orders the required 
inventory from the CMO and the customer is given a tracking 
number. Once the inventory is available the customer order will be 
filled. If the customer order was partially filled, the remaining 
quantity will be filled. 


• The LSM may cancel the customer order whether or not there is 
inventory available in stock. 


с. Processing Customers’ Orders by the Global Store Managers 


GSMs take follow up actions on the orders placed by LSMs. A GSM has 
control over the inventory available in all the stores. Again, the ordered inventory may be 
available, in the main store or in any warehouse other than the one that onginated that 
order, partially available, backordered, or not available at all. As illustrated in Figure 7, 


the GSM processes the orders in the following manner: 


Inventory Levels 


Minimum Order Quantities 
Further 


Processing 


IOTS Database Order of Customer 
EET у Order 


Issued, Due-Out, Canceled, or Deleted Order 





Figure 7. Processing Customer Order by GSMs 


• If the inventory is available the order might be filled in full, or 
partially filled. 


а. 


If the inventory is not available the GSM may put the orders in a 
"Dues out" state in order to get the inventory later from the 
suppliers. Once the inventory is available, the orders might be 
filled in full. If the customer order was partially filled, the 
remaining quantity might be filled. 


The GSM may cancel the orders whether or not there is inventory 
available in stock. 


Orders that have been filled, but not picked up by the customer for 
a predetermined period of time, are deleted and become available 


to be issued to another customer. 


Ordering Inventory from the Suppliers 


This activity is carried out by a specialized staff that reads the inventory 


levels, the Dues-out orders, and places these orders to the suppliers. The DFD for this 


activity is shown in Figure 8. 


The suppliers will take action on these orders according to their own 


policies. Once an order is filled and shipped to the warehouse that originated the order, 


the customer will be notified to pick it up. The processed invoice 1s sent to the ACS, 


which will take care of the accounts payable to the suppliers. 
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Figure 8. Ordering the Inventory from the Supplier 


So far, it is clear that the customer order goes through a sequence of state 
changes. The availability or the unavailability of the required inventory governs the life 
cycle of any given order. The state diagram, Figure 9, illustrates how the state of any 
given order may change and traces the state changes that a customer order may 
experience during its life cycle. The customer order will be in one, and only one, of the 


following States: 


• Booked Locally. The inventory is reserved for the customer and 15 
waiting for the customer to pick it up. 


Booked by Main. The inventory is reserved for the local 
warehouse and is waiting to be picked up. 


Confirmed/Closed. The order is filled. 
Deleted Locally. The order is deleted due to the fact that the 
customer no longer needs the inventory already reserved for him or 


her. 


Deleted by the GSM. The local warehouse no longer needs the 
reserved inventory. 


Canceled. The order is either canceled by the LSM or by the GSM. 
Waiting. The customer order is waiting to be filled. This waiting 
state will eventually end in one of the following states: Canceled, 


Booked Locally, and Deleted by GSM. 


Due-out. The GSM places the order in a “Due-out” state, that is, 
waiting to be ordered from the suppliers. 


Due-in. The supplier will fill these orders. 
Shipped. The supplier filled the order. 


Not Available. The supplier does not, or no longer supplies the 
ordered inventory. 
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Figure 9. State Transition Diagram 





52 How Much Analysis is Needed? 


The logical DFDs listed in Figures 5, 6, 7, and 8 can be decomposed further and 
further in order to obtain more details about the current system. Some experts say that 
analysts should start as quickly as possible with the new logical DFD, and not spend 
much time in analyzing the current system (Hoffer, 1996, p. 330). We subscribe to this 


view for the following reasons: 


• The DFDs of the current system tend to give both the analysts and the 
users more knowledge about the system under analysıs. Since both the 
analysts and the users are familiar with the system, further decomposition 
of the system will not justify the cost of the time spent on further 
decomposition. 


• The DFDs make it easy to add new functionalities or to eliminate some of 
the existing ones. The users are mainly satisfied with the current available 
functionalities, but not with the implementation. Thus, there is a need to 
focus on the new implementation of the IOTS and not to spend much time 
in analyzing the functionalities of the legacy applications. 


• The major goal of this research is to build an IOTS prototype that 
addresses the interoperability, portability, platform independence, and how 
to reimplement the system in a way that gets the benefit of the currently 
available technology enhancements. Ihus, we focus on how the new 
implementation of the IOTS may address these issues, and what potential 
benefits the migration to anew open, Web-based IOTS may provide. The 
QSI needs to form a group of system analysts in order to conduct a more 
thorough analysıs of the current and proposed system. Our experience 
suggests that a complete study and ımplementation of such a complex 
system may take a group, including all of the necessary specialists, from 
about eight to twelve months. 


D. THE PROBLEMS OF THE CURRENT IOTS - 


The problems listed below were not thought to be problems several years ago. The 
emergence of the Web-based technology, enhancements in the client/server architectures, 
the decrease in the price of personal computers, and the existence of platform- 
independent programming languages introduced new ways of doing business. This new 


technology is considered revolutionary compared to what was available just a decade ago. 


To benefit from these technological advancements and enact business ın a more efficient 
and economical way, we ıdentify the following problems in order to find a solution. 
These problems fall into two major categories: problems imposed on the IOTS by the 
environment it operates in, and problems that are specifically related to the way the IOTS 


was designed and implemented. 
1 Problems Imposed by the Environment 


The environment affects the IOTS in the following areas: 

Portability. The IOTS is designed to work on a specific type of a mainframe and 
in a UNIX operating system environment. This platform and operating system 
dependence has substantial impacts on the system. Thus, the QSI is tied to some limited 
choices of technology; for example, every time the QSI wants to procure or develop a 
new enhancement on the IOTS computerized system, it must be determined if, and how, 
this new system will interoperate with the legacy systems. 

Cost. The cost of maintaining the mainframe is very high and maintenance 
requires a high level of expertise that is usually not available in-house and therefore must 
be outsourced. The maintenance cost of desktop computers however is far less expensive 
and can be performed in-house. Although putting the power of a large mainframe 
computer on a desktop 1s possible, the cost of administering desktop computers that each 
of which may be configured slightly differently, can be significant and possibly 
overweigh their advantages. The expected savings may not materialize because of 
unexpected hidden costs; for example, the savings in desktop hardware acquisition are 
often offset by high annual operating costs for additional labor required to administer and 
maintain the network. 

The final word on whether the proposed system will provide cost savings or not 1s 
left to a specialized detailed cost-benefit analysis which is beyond the scope of this 
research. The cost-benefit analysis shall consider many issues such as the cost of 
hardware/software procurement, the cost of maintain the legacy code, the cost of the 
development of the new system, the cost of administering the system and training the 
users to adjust to work in the new environment, and the potential benefits of the new 
system. Therefore, the QSI needs to plan and manage change carefully in order to get the 


benefit of the new technology. 
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Interoperability. To circumvent the problem of communicating efficiently 
between the MIS and the IOTS, a batch process ıs used. This process extracts data from 
the mainframe and uses it to update the MIS applications running on the PC LANs. 
Therefore, the data on the PC LANs are not up-to-date and may not reflect the real 
Situation. 

Information infrastructure. The intervening batch process, between the 
computerized systems on the PC LANs and the ones on the mainframe, gives an example 
of how vexing the current information infrastructure is. This batch connection process 
results in redundant data maintained by different systems and leads to a waste of 
computer resources, manpower, and time. The data redundancy may also lead to a lack of 


data integrity in case an update is not performed appropriately. 
2: Problems in the Design and Implementation of the IOTS 


Legacy code. The IOTS application tnes to handle every possible requirement the 
developer could conceive. Such an application is hard to develop, difficult to maintain, 
and almost impossible to adapt to future needs in a reasonable amount of time. 

No GUIs. The users are not comfortable with the text-based user’s interface. They 
need to interact with the IOTS application via a graphical user interface that makes their 
job easier and more interesting. | 

Weak supply chain. Customers are not able to place and track their orders, which 
calls for the QSI to maintain qualified LSMs just for placing and tracking these orders. 
Moreover, a limited number of customers are reachable. In today’s world, not many 
customers can afford the time to go to a warehouse, place an order, and then come back to 
pick up their ordered items once filled. Indeed, a reasonable number of customers prefer 
to get their orders shipped to their places. For the QSI to stay in business, ıt needs to 
retain its current customers and look for ways to increase them. 

Orders sent to suppliers do not show a real-time state. Suppliers send the states of 
these orders by fax or mail, and the QSI enters these states to the IOTS in order to refresh 
the states of these received orders. Therefore, the states of orders on the IOTS database do 
not reflect the real situation and are not up to date. 

The reports listed in Appendix D are generated offline due to the high processing 
time requirements. These reports are ordered manually from a separate specialized party 


in the CMO that generates and supplies these reports. Users are satisfied with the 
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functionalities provided by these reports, but they need to be able to track their ordered 


reports the same way they track their ordered inventory. 
E. WHAT A MODERN IOTS SHOULD BE 


In this section we first discuss the business drivers that call for the reengineering 


of the legacy IOTS. Next, we list the requirements of a new IOTS. 
le Business Drivers 


There are two main reasons that call for keeping the current legacy system as it is. 
First, 1t provides a vital service that 1s very risky to disrupt. Second, the current users are 
used to this system and switching them to a new system requires additional training. 
Since the reengineenng process involves risk and incurs additional cost, there must be 
strong business drivers that motivate the effort of reengineering before fully launching it. 
Amjad Umar broadly categones the business drivers that motivate application 


reengineering as follows (Umar, 1997, p.105): 


• Business process reengineenng 
• New services or business opportunities 
• To gain and maintain a competitive edge 


• To alıgn IT with business 


The reengineering process of the IOTS is motivated or dnven by factors that 
mainly lies in the last three categories listed above. A more detailed study, however, may 
reveal that this application reengineering process should go side by side with a business 
process reengineering. The QSI will face a drastic change in the way of doing business 
and it needs to reorganize in a way that enables it to work in the new open environment. 
The following are the business drivers that are particularly related to the + SI: 

Supply chain management. The supply chain management integrates both 
buyers and sellers chain processes, which provides the QSI a more competitive advantage 
and enables it to work in the open environment. As discussed earlier, the QSI is not 
connected to suppliers in real-time and, therefore, the QSI's records are not up to date. 
Customers are not able to place and track their orders. The QSI maintains additional staff 


just to serve customers who call to inquire about their orders. The integration of buyers 
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and suppliers is “critical for speed and responsiveness in today’s hypercompetitive 
product and service markets” (Nissen). Integrating the supply chain promises the QSI a 
more efficient way of conducting business. For example, since customers will be able to 
place and track their orders, the QSI may downsize its customers’ service staff, which 
results in cost reduction, at least in terms of manpower. 

Maintain competitive edge and investigate new business opportunities. Many 
businesses are building new electronic commerce systems in order to gain a competitive 
edge in this rapidly growing area. The QSI wants to keep pace with this trend and benefit 
from the new opportunities made available by the emergence of Web-based technology, 
enhancements in client/server architectures, decrease in the prices of desktop computers, 
and the existence of platform-independent programming languages. 

Legacy code, interoperability, and platform dependence. The QSI wants to 
overcome the limitations of its legacy code, not be restricted to a specific platform or 
operating system, and achieve system-wide interoperability. 

Cost reduction. Cost reduction is always a goal that drives businesses. The 05115 


no exception and needs to conduct its business in a more cost-beneficial way. 
2: IOTS Requirements 


The requirements of the reengineered IOTS support the business-drivers already 
discussed and provide the major source of motivation to this research’s proposed 
solution. In the next chapters, we describe our implementation of a prototype system that 
is based upon these requirements. We explore how implementing these requirements will 
contribute to the solution of the problems that have been identified. Moreover, the 
research will investigate what additional benefits will be gained from adopting the 
modern technology in addition to just solving the existing problems. The IOTS must 


support the business goals by providing the following requirements: 


• Take advantage of the Web technology by directly connecting to the 
suppliers, enabling the customers to place and track their orders, and 
having orders shipped to the requested destination. 


• Track the status of a customer order across all of the warehouses. Refer to 
Figure 9, the state transition diagram, and its explanation in the analysis of 
the current system, for a better understanding of this requirement. 


Consist of software components that can be developed, purchased, rapidly 
customized, and integrated into heterogeneous multitier platforms. 


Run on all platforms in order to facilitate future integration of IOTS with 
other systems such as ACS, PERS, and MIS under a common Enterprise 
Information System (EIS). 


Be easy to maintain. 
Provide cost reduction. 


Provide freedom in selecting application programming languages; 
applications written in different programming languages must be able to 
interoperate with each other. 


Provide a graphical user interface that must be: 
• easy to use (1.е., user-friendly) 


• informative and explanatory in terms of providing clear error 
messages that direct the user to perform a clear action (e.g., 
mysterious error messages are not acceptable) 


• highly flexible, in order to handle users at all levels of proficiency 


• able to support different access levels to information on a “need-to 
-know” basıs. These levels are: 


• Level zero: This is the highest access degree in which 
Strategic managers will have access to everything in the 
system. MIS users are the core of this category. 


• Level one. This is the second highest level of access that is 
associated with the Global Store Managers (GSMs). The 
GSMs will have access to the entire available inventory, 
regardless of which store this inventory is located. 


• Level two. This level 1s associated to Local Store Managers 
(LSMs). LSMs will have access to the inventory available 
in their local warehouses only. They are not authorized to 
query or contro] items on stores that are not under their 
span of control. 


ө Level three. This level is for regular users who will have 
query privileges only. The access to the IOTS from the 
ACS will also have this access level. 


• Level four. This level ıs granted to customers accessing the 
system from the internet. They will be allowed only to 
place and track their orders. 


Develop a centralized relational database which will store the necessary 
information about different items offered for sale by the QSI. This 
database must support Web access. 


Allow the authorized personnel, based on their access levels, to access the 
information in the centralized database, inquire about the available 
balance, place orders, and inquire about the status of their orders. 


Provide the queries listed in Appendix C. 


Provide the reports listed in Appendix D. Users must be able to track the 
status of their ordered reports. Any ordered report will be in one of the 
following states: Waiting, Canceled, Ready, or Confirmed. “Waiting” 
means the ordered report is under processing. “Canceled” means the 
requested report order 1s canceled and a comment will display the reason 
of cancellation. “Ready” means the ordered report is ready and can be 
picked up. The “Confirmed” status indicates that the report was physically 
handed to the requesting party. The only printing jobs that will be provided 
online are the ones that do not delay the user for a long period of time, 
such as printing a limited number of vouchers, invoices, or copies of the 
screens that are usually generated by the queries listed in Appendix C. 


SUMMARY 


The current IOTS provides the following eight major activities: order entry, 


receiving, accounting, purchasing, stocking, planning, and decision-making. 


The major problem that calls for reengineering the current legacy IOTS is its poor supply 


chain. In the current system, customers are not able to place and track their orders, the 


QSI is not connected to the suppliers in real-time, and various inventory ordering and 


tracking activities cannot easily interoperate with each other. Supply chain management 


integrates both sellers’ and buyers’ processes to increase the system’s responsiveness and 


competitiveness by benefiting from the revolutionary advancements in technology. This 
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Chapter also discusses the business drivers that call for the reengineering process. These 
business drives provide the major source of motivation to this research’s proposed 
solution. The requirements were listed to support these business drivers and motivate a 
solution for the identified problems. In Chapter IV we start building the IOTS prototype 


based on these requirements. 


IM. TECHNOLOGICAL BACKGROUND 


This chapter provides a brief overview of Relational Databases and SQL, Java and 
JDBC, and CORBA. The purpose of this chapter is to provide the readers who are 
unfamiliar with these technologies with the background knowledge needed to understand 
the proposed solution for the IOTS. For more details on the material covered in this 


chapter, the reader may refer to the list of references. 


A. RELATIONAL DATABASES AND SQL 


Т; Relational Databases 


The focus of this section is on the relational database model that is used in the 


implementation of the IOTS prototype database. 
a. What is a Database? 


A database is a structured collection of related data. A database is 
restricted to some implicit properties; it represents some real-world aspect, consists of a 
coherent collection of data that has inherent meaning, and is designed, built, and 


populated for a specific purpose. (Elmasn, 1994, p. 2) 
b. Database Approach vs File Processing Approach 


Database technology evolved to overcome the limitations of the traditional 
file-processing approach. In the file-processing approach, each user designs and 
implements the files needed for a specific application. In the database approach, the 
database forms a single repository that is defined once and accessed by multiple users 
each of whom may see a different view of the database. The difference between these 
approaches is important because neither end users nor programmers need worry about 
how data is physically stored in the database. This promotes application data 
independence wherein the database is managed by a Database Management System 
(DBMS) rather than the application programs. 

The Database processing approach provides several advantages: it reduces 
data duplication, restricts unauthorized access, defines deduction rules in order to infer 


new information for the facts stored in the database, defines and enforces integrity 
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constraints, provides tools for backup and recovery, enables the Database Administrator 
to enforce standards, reduces application-development time, permits changes to the 
structure as the requirements change, and makes the data available to authorized users in 


an up-to-date state. (Elmasrı, 1994, pp. 12-16) 
С. Database Management System 


A Database Management System (DBMS) ıs a set of programs that 
enables users or programmers to create and maintain a database. With the help of a 
DBMS, users are able to define the structure of a database, populate the database with 
data, and manipulate this data. A DBMS must provide enough functionality to manipulate 
both the database and its meta-data. The database and the software form together what is 
called a database system. Figure 10 shows a simplified database system environment 
(Elmasn, 1994, pp. 1-2) 


Users/Programmers 


Database Programs/Queries 


Software to Process 
Queries/Programs 


Software to Access Stored 
Data 


Stored Database Stored Database 
Definition 
(Meta-Data) 





Figure 10. A Simplified Database System Environment (Elmasri, 1994, p. 2) 
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Accessing the database through the DBMS makes the application 
programs independent from the data. Application programmers do not have to worry 
about the ways in which data are physically stored in the database. At one time, there was 
a clear boundary between the application programs and the DBMS; programmers had to 
use a third generation language to access the database. Today, however, most DBMS 
have some extended capabilities to generate forms and reports that can ultimately be 


integrated in user’s applications. 
d. Relational Databases and Data Model 


Database engineers define four different types of databases: Relational, 
Hierarchical, Network, and Object-oriented databases. The most common type in today’s 
business world is the relational model. Figure 11 represents an example of a database 
maintained by a hypothetical company to track its employees and their dependents. The 
Figure shows the database structure and a few sample data records of such a database. 
Although relational databases faced some resistance in their early days, partly because of 
their high consumption of computer resources (Kroenke, 1998, p. 17), the relational 
model gained acceptance quickly in academic institutions because it is built on a provable 
mathematical foundation that hastened the process of developing a generalized query 


language (Taylor, 1999, p.24). 


EMPLOYEE 


Emp_Name Date_Hired Phone_Number Monthly_Salary 
1235 Mark Thomas | 12-Feb-69 831-123-4567 $3000.00 

1346 23-Oct-80 408-675-8900 $5500.78 

2385 15-Jan-86 408-890-9999 $3500.59 


DEPENDENTS 


Figure 11. A Database Example 
















ОЙ 


In the relational model, data is stored in a certain way that minimizes 
duplicated data and eliminates certain types of processing errors. The relational model 
uses a process called normalization to break down undesirable tables into two or more 
desirable ones (Kroenke, 1998, p. 17). Several levels of normalization have been defined. 
Each level is used to examine the entity and its attributes to decide what attributes belong 
and do not belong to that entity. 

"А data model is a set of concepts that can be used to describe the 
structure of the database.” (Elmasn, 1994, p. 23) A relational data model represents the 
relational database as a collection of relations (tables). Each relation represents a data 
entity, and each entity is a collection of data attributes (columns). Relationships represent 
the interaction among these entities. An entity 1s an object about which we want to record 
information. An example of an object is an employee (see Figure 11). Possible attributes 
about this object are name, date hired, phone number, and monthly salary. In order to 
maintain entity integrity, each table must have a unique column value called a primary 
key. Any column that 1s a part of the primary key cannot be null. EMPLOYEE table uses 
Emp_No as a primary key whereas DEPENDENT table uses both the Emp_No and the 
Dependent_Name to uniquely identify a single record. Foreign keys are used to define 
relationships between relations. A foreign key in one relation is a reference to a primary 
key in another. An example of a foreign key in the DEPENDENT table is Emp_No, 
because it refers to a unique employee in the EMPLOYEE table. If a tuple (row) in the 
DEPENDENT table refers to another tuple in the EMPLOYEE table, the employee tuple 
must exist; this situation is referred to as referential integrity. A relationship can be one 
of these forms: One-to-One, One-to-Many, and Many-to-Many. “One-to-One” means for 
every occurrence of an instant of data in an entity, only one instance will occur in another. 
“One-to-Many” means for every single occurrence of an instant of data in one entity, 
many instances of data may occur in the other table. An example of this type 1s 1llustrated 
in Figure 3.2 where each employee in the EMPLOYEE table may have one or more 
dependents in the DEPENDENTS table. Finally, “Many-to-Many” means for multiple 
instances in a given entity, there are one or more instances in the related entity. 

There are many high-level conceptual data modeling techniques that 
facilitate the database design process. One of these techniques is Semantic Object 
modeling which will be used in the next chapter in order to provide a high-level 


representation of the IOTS database. 
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2: Structured Query Language 


IBM developed Structured Query Language (SQL) (pronounced SEQUEL) at their 
research facility. Nowadays, SQL is a standard in the relational database industry. 
Relational database users quickly learn this language because it expresses its logic with 
English-like syntax. SQL is a comprehensive database language with two types of 
statements: Data Definiion Language statements (DDL) and Data Manipulation 
Language statements (DML). The DDL allows the creation of database tables and allows 
the creation of views on the top of these tables. The DML statements are used for 


querying and updating the database. 
a. SOL Commands 


A list of the most frequently used SQL commands and a brief description 


of each one of these commands is shown in Table 1. 


CREATE Used to create tables | 


SELECT This is the most frequently used command. Usually the SELECT 


INSERT Used to add a row into a table that already exists 


UPDATE Used to modify a record or more of data that meets a specified 
DEFETE 


Table 1. A List of the Most Frequently Used SQL Commands 


















command statement consists of three main clauses: SELECT, 
FROM, and WHERE. The WHERE clause is optional. Normally, 
the SELECT keyword is followed by a list of columns, the FROM is 
followed by a list of table names, and the WHERE is followed by 
one or more search conditions. Sometimes the keyword DISTINCT 
is optionally used after the SELECT command to remove any 


duplicate lines from the query results. 





condition. 


Used to delete a row or more of data that meet the condition 


specified in the WHERE clause 








ES 


Command | Syntax 


CREATE CREATE TABLE 
<tablename> (col-def, 
..., col-def, tab-constr, 
.... tab-constr); 

ЗЕБЕСІ SELECT [distinct] 
<expression> 
FROM <tablename> 
[WHERE 
<search-condition>]; 





Example 


To create the EMPLOYEE table: 


CREATE TABLE EMPLOYEE ( 
Emp. No number(4) primary key, 
Emp. Name varchar2(30), 
Date Hired date, 
Phone Number  char(12), 
number(6,2) ); 
To list the numbers and the names of all the 


employees whose monthly salary is greater than 


$5000.00: 


SELECT Emp_No, Emp_Name 
FROM EMPLOYEE 





INSERT INSERT INTO 
<tablename> [(column 
{, column})] 
VALUES (expression 
{ expression }); 

UPDATE UPDATE 
<tablename> 
SET <column>= 
<expression> ... 
[WHERE <search- 
condition>] 

ОРЕ ЕТЕ DELETE FROM 
<tablename> 
[WHERE <search- 
condition>] 


WHERE Monthly_Salary> 5000.00; 
To add a new employee to the EMPLOYEE table: 


INSERT INTO 

EMPLOYEE(Emp_No, Emp_Name, Date_Hired, 
Phone_Number, Monthly_Salary) 

VALUES (1453,”Susi Kamil”, 13 Nov 94, 831- 
642-8900, 6000.00); 

To change the phone number for the employee 
named Maher Tony : 

UPDATE EMPLOYEE 

SET Phone_Number = 408-657-9342 

WHERE Emp_Name = ‘Maher Tony’; 





To delete the employee record for the employee 


with the employee number equal 1235: 
DELETE FROM EMPLOYEE 
WHERE Emp_No = 1235; 


Table 2. Examples on the Most Frequently used SQL Commands 
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Table 2 shows the syntax of these commands in a very generic form, and 
presents an example of each command. These examples use the sample database shown 


in Figure 11. 
b. How SOL is Used 


Using SQL directly on top of a database is helpful in defining the structure 
of the database and providing quick ad hoc queries, but it is not very useful in building 
highly sophisticated applications. To build such applications, there are different ways to 
use SQL in order to manipulate the data in a given database, such as embedding SQL 
statements in a high-level third generation language. This is called Embedded SQL 
(ESQL). The ESQL statements are identified within the host language by marking their 
starting and ending points with special delimiters. Before compiling the host code with a 
native language compiler, a precompiler is used to convert ESQL statements into an 
equivalent host-language code. One major limitation to the ESQL 15 that the host program 
must know the type of the database it 1s going to connect to during the program 
development, and precompilers have been tied to particular database products (Orfali, 
1998, p. 526). 

Another way to execute SQL statements is called stored procedures. A 
stored procedure is a predefined and compiled procedure stored in the database that is 
available to be used by clients’ applications and can be called by name. 

Stored procedures have many benefits; after the first execution of the 
stored procedures there is no need to parse, optimize, or compile them again. The stored 
procedures are executed with a single sentence even though they may consist of multiple 
queries. Parameters are passed to a stored procedure enabling different clients to access 
the same stored procedure. Finally the stored procedures are fast in the client/server 
environment. Stored procedures, however, have some problems; they are vendor-specific, 
non-standard, and not portable across platforms. (Akbay,1999) қ 

The following is a simple example on a stored procedure that is used to 
calculate the summation of the monthly salaries of all the employees listed in Figure 11. 
In practice, stored procedures can be used to perform more sophisticated tasks: 

CREATE or REPLACE PROCEDURE sumSal (sal OUT NUMBER(8,2)) 

AS 


BEGIN 
SELECT SUM(Monthly_Salary) INTO sal FROM EMPLOYEE; 
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END: 


JDBC ıs another method used for sending SQL statements to relational 


databases. We defer the discussion of this method to the next section. 
3. Summary 


A database is a structured collection of related data. It evolved to overcome the 
limitations of the traditional file-processing approach. A database processing approach 
reduces data duplication, restricts unauthorized access, defines deduction rules, and 
enforces integrity constraints. А DBMS enables users to create and maintain á database. It 
makes application programs independent from the data. The relational model gained 
acceptance quickly because of its provable mathematical foundation. It represents the 
relational database as a collection of relations (tables). Each relation represents a data 
entity, and each entity is a collection of attributes. 

The SQL is a standard in the database industry. It is easy to learn and use, and it 
consists of two parts: DDL and DML. The SQL can be used directly on top of a database, 
embedded in a high-level third generation language or as a predefined and compiled 
procedures stored in the database. Although stored procedures provide many benefits, 


they are vendor-specific, non-standard, and not portable across platforms. 


B. JAVA AND JDBC 


1. ЈАУА 


Java is an објес!-опепјед programming language developed by Sun 
Microsystems, which was formally announced in a major conference in 1995. Java 
attracted attention rapidly because it was designed for commercial business applications 
on the World Wide Web. Java applets are pieces of code that can be embedded in Web 
browsers. Applets can vary between little decorations and serious applications. 

A major advantage of Java is its portability. Applications written in Java will 
execute on all major platforms. This cross-platform operability is provided by the Java 
Virtual Machine (JVM) that provides a run-time environment for running Java 
applications. Java source code is compiled into bytecodes, instead of machine code that 


is platform dependent. JVM executes these bytecodes directly or translates them to a 
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language understood by the machine running it. This feature leverages the desired cross- 


platform operability required by the IOTS. 


a. 


Java Features 


Garbage collection - unlike other languages such as C++, Java 
takes care of allocation and deallocation of memory. Therefore, the 
burden of performing this task is no longer imposed on 
programmers. Unused memory resources that are no longer 
referenced are automatically removed in order to stop memory 
leaks that may cause applications to crash. 


Extensibility — Java enables programmers to extend the existing 
classes or write their own classes. The JDBC, explained later, is an 
example of Java extensibility. Other extension areas are 
multimedia, electronic commerce, and conferencing. 


Simplicity — Writing programs in Java is similar to C++, which 
makes it easy to learn for those who know C++ already. However, 
Java has eliminated the error-prone parts of C++, such as pointers, 
multiple inheritance, preprocessors, and operator overloading. 


Strong typing — Java enforces strong type checking. Therefore, 
many errors are caught at compilation time. 


Network friendliness — Java’s built-in features facilitate 
client/server applications, and remote access to databases. 


Scalability — Java’s scalability comes from its operating system 
independence. JVM enables Java-based applications to run on a 
wide range of platforms. 


Multi-threaded — Threads give Java programs the ability to do 
more than one function at the same time. This feature supports 
multimedia, and networking, due to the inherent slowness of 
network connections. To imagine this feature, think of a Јама 
application that plays audio and displays text at the same time. 


Security — Java has some built-in secunty features. One feature is 
that JVM subjects any incoming code to its verifier that ensures the 
incoming code is correct, does not violate access restrictions, and 
does not forge pointers. Additionally, Java loader differentiates 
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between local class and classes imported from across the network. 
JVM does not allow the substitution of local classes by imported 
ones. Another important security feature 1s that JVM does not 
allow untrusted applets to access the local machine. 


b. Java Development Environment 


Typically, Java programs go through five phases to be executed. These 
phases are as follows: edit, compile, load, verify, and execute. Figure 12 (Deitel, 1998, p. 


15) shows a typical Java environment. 


Bytecode Venfier 


Interpreter 





Figure 12. Typical Java Environment (Deitel, 1998, p. 15) 


• Editor — enables programmers to create and edit Java programs. 
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• Compiler – generates the bytecode from the source code and stores 


it to disk. 
• Class Loader — places bytecode in memory. 
• Bytecode Verifier — ensures that the bytecode satisfies the Java 


security model. 


• Interpreter — translates the bytecode into a machine language that 
the computer can execute. 


2. JDBC 


JDBC ıs a Java Application Programming Interface for executing SQL statements. 
JDBC is used to send SQL statements to relational databases. Thus, it is not necessary to 
write an application program to access each different database, such as Oracle, Informix, 
or Sybase. Rather, a single application program is written once using a JDBC Application 
Programming Interface (API) which will access the appropriate database by sending SQL 
commands. Java is secure, robust, and platform-independent whereas JDBC makes it easy 
to access relational databases by clients that are running on different platforms, for 
example, accessing a remote database from an applet running in a Web browser. JDBC 
makes it possible to derive the benefits of client/server systems and object-oriented 
languages yet still be able to access the legacy relational databases that businesses have 
huge investments Іп. 

JDBC is a low-level API designed for building higher-level APIs that are more 
convenient and user friendly. There are two kinds of high-level APIs: (1) mix SQL 
Statements directly with Java. For example, a Java variable can be used as a parameter in 
an SQL statement to pass or receive SQL values; (2) map the relational databases directly 
to Java classes; each table is mapped to a Java class, each row becomes an instant of that 
class, and each column value is mapped to an attribute of that instant. An example 
product of the first kind is JSQL and Java Blend is an example of the second kind. 
(Hamilton, 1997, pp. 6-7) 
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а. The JDBC Architecture 


The JDBC architecture is best illustrated by Figure 13 (Orfali, 1998, p. 
528). The Dnver Manager is the backbone of the JDBC. Its main function is to connect 
the Java application to the suitable JOBC dnver. The JOBC-ODBC bndge enables the 
JDBC to use Open Database Connectivity (ODBC). It was developed as a quick start to 
connect Java to SQL databases. The JDBC-ODBC provides access for databases when 
JDBC drivers are not implemented for them. ODBC binary code must be loaded on each 
client machine. Therefore, this kind of driver is appropriate for corporations for which 
installing client applications is not a problem. It is also appropriate on servers that are 


built in a three-tier architecture. 


Java Java Java 
Application Application Application 


m 
JDBC 


API 


JDBC to ODBC Driver to Driver to Driver to 
Driver Sybase DB2 Oracle 


OPEC DI | 


| 


A PE 
MS SQL Sybase Oracle 


Server Database Database 





Figure 13. The Layers of JDBC (Orfali, 1998, p. 528) 


b. JDBC Interfaces 


Orfali and Harkey (Orfali, 1998, pp. 532-567) classify JDBC interfaces 


into the following four groups: 
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• JDBC core interfaces. 

These are the interfaces and the abstract classes that must be ımplemented 
by every JDBC driver. These classes are basically used to locate the DBMS drivers, 
establish connections, submit SQL statements, and process the result sets. They 
perform over 90 percent of what you do with a database. Figure 14 shows these 


classes and interfaces. 


• Java language extensions. 
These are the new required extensions for SQL, because the JDBC requires 
dealing with high-precision data types that are mostly used to process data 
representations of money. SQL also defines its own exception and warning types that 


should be grafted into Java. Figure 15 shows Java.sql extensions for Java.lang. 


Driver Connection Statement ResultSet 
Interface Interface Interface Interface 


DriverManager PreparedStatement ResultSetMetaData 
Class Interface Interface 


DriverPropertyInfo CallableStatement 
Class Interface 





Figure 14. The JDBC Core Classes and Interfaces (Orfali, 1998, p. 533) 
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Figure 15. Java Language Extensions (Orfali, 1998, p. 535) 


• Java utility extensions. 


Java extends the Java.util.Date class to get three new classes defined in 
Java.sql in order to meet the requirements of having fine-grained time and date utilities. 
These new classes allow the user to measure the time in nanoseconds. These classes are 


shown in Figure 16. 
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| Java.lang 


TimeStamp 
Class 


? Tava cal 





Figure 16. Java Utility Extensions (Orfali,1998, p. 536) 


Ф SQL metadata interfaces. 


This interface standardizes the access to the database metadata 
across multiple DBMS vendors. This interface consists of 133 methods that should be 
implemented by JDBC vendors. 


DataBaseMetaData TypesClass 
Interface Class 





Figure 17. The Java.sql Metadata Interface and the Types Class(Orfali, 1998, p. 537) 
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Figure 17 shows the Java.sql Metadata Interface and the Types class. The 
Types class is just a placeholder for constants and does not support any methods. (Orfali, 
1996 РР 652 — 507) 


с. Accessing a Relational Database with JDBC 


With JDBC, performing the following tasks ıs easy: 


• Establish a connection to a database. 
• Send SQL statements. 
. Process the results. 


The following is a brief description of the above JDBC capabilities: 
(1) Establishing a connection with the database 


To perform this task, the driver must be loaded first. Then a 
connection is made. For example, to load a JDBC-ODBC driver, the following single line 
of code might be used: 

Class.forName (“sun.jdbc.odbc.JdbcOdbcDriver”); 

There might be a need to refer to driver documentation to get the 
class name of that particular driver. For example, if a class name for a driver is 
Jdbc.DriverX, then you would use the following statement to load the driver: 

Class.forName ("Jdbc.DriverX"); 

Once the driver is loaded, the connection can be established. For 
example, if you are using a JDBC-ODBC driver to connect to a Microsoft Access 
database, with a source name = IOTS_DB, user name = “guest”, and a password = 
“Moon”, you would use the following statements: 

String url = “Jdbe:odbe:lOTS_DB”; 

String login = “guest”; 

String password = “Moon”; 

Connection con = DriverManager.get Connection (url,login, 

password); 

You may need to refer to the documentation of the driver's vendor 


in order to figure out the syntax of the URL parameter in the getConnection method. 
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(2) Send SQL Statements 

In order to execute SQL statements on the database, we use the 
connection object created already in the previous step to create a statement object. If the 
SQL statement intends to query the database, the executeQuery method of the statement 
object is executed; otherwise if the SQL statement attempts to create or modify a table of 
the database, the executeUpdate method is used instead. For example, to create the 
ORACLE EMPLOYEE table listed in Figure 11, the following set of statements are used: 


String createStatement = "CREATE TABLE EMPLOYEE ( 
+ “Emp_No number(4) primary key, * + 

“Emp_Name Varchar2(30), “ + 

“Date_Hired date, “ + 

“Phone_Number char(12), * + 

“Monthly_Salary number(6,2) 

Statement stmt 2 conn.createStatement(); 
stmt.executeUpdate(createStatement); 


(3) Processing the results 


The results of a SELECT statement are returned in a ResultSet 
object. This object provides a set of useful methods to manipulate the returned object. 
One of these methods is the next() method. This method moves the cursor form the 
current row of the ResultSet object to the next row. The following statements would be 
used to list the numbers and the names of all the employees whose monthly salary is 
greater than $5000.00: 

String query = “select Emp_No, Emp_Name “ + 

“from EMPLOYEE “ + 

“where Monthly_Salary> 5000.00 *; 

Statement stmt = conn.createStatement(); 

ResultSet rs = stmt.executeQuery(query); 

System.out.printinEmployee Number Employee Name’; 

System.out.printiIn(“---------------------- | ------------------- 

while (rs.next() ) { 

Integer empno = rs.getint(““Emp_No’); 
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String name= rs.getString(“Emp_Name”); 
System.out.printin(empno+“ “ + пате); 


} 


d. JDBC and the Client/Server Models 


The JDBC API supports database access utilizing both two-tier and three- 
tier client/server models. What decides the client/server tier level is the way in which 
major functional components of an application are split between the client and one or 
more of the servers. The typical functional units are the user interface, the business logic, 
and shared data. Two-tier client/server systems have the business logic either inside the 
user interface on the client, or the database server (or both); whereas three-tier 
client/server systems have the business logic on the middle tier separate from both the 
user interface and the data. Three-tier client-servers systems are more scaleable, robust, 
and flexible. Moreover, they can integrate data from various sources. (Orfali, 1998, p. 
583) 

(1) JDBC Two-tier 


Tier | Tier 2 
Client Database Server 





Figure 18. JDBC Two-tier (Orfali, 1998, p. 584) 
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This model is called the “fat client” approach since the client holds 
the business logic and maintains all the JDBC drivers. Figure 18 shows a two-tier 
client/server split. 

The load on the client can be reduced by using stored procedures 
that lie on the database. However, the stored procedures are non-standard and the user 
might be locked into a proprietary vendor implementation. To achieve portability, stored 
procedures should not be used.(Orfali, 1998, p. 583) 


(2) JDBC Three-tier 


This approach moves the business logic from the client to the 
middle tier. Applications that access the data run on the server side in addition to the 
DBMS engines. The databases can be run on separate server machines. Figure 19 shows 
the JDBC three-tier client/server split. (Orfali, 1998, p. 586) 
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Figure 19. Three-tier (Orfali, 1998, 586) 


The above figure shows that the Object Request Broker (ORB) ıs 
used as a communication backbone between the client and the application server. We 
describe the ORB in much more detail in the next section. The three-tier model is 


attractive because the middle tier makes ıt possible to maintain control over access and 
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types of updates that can be made to the data. Only the middle tier knows how to find and 
manipulate data. So, the middle tier can be thought of as an intermediate security level 
that shields the client from direct access to the database. Moreover, the clients can be 
designed to use a higher level API that can be translated into a low-level call by the 


middle tier. 
З, Summary 


Java is an object-oriented programming language. It has attracted attention mainly 
because of its features such as portability, garbage collection, extensibility, simplicity, 
strong typing, network friendliness, multi-threading, and security. Typically, Java 
programs go through editing, compiling, verifying, and executing phases. JDBC 15 a low- 
level API that establishes a connection with a database, sends SQL statements, and 
processes the results. The JDBC supports database access utilizing two-tier and three-tier 
client/server models. The three-tier architecture makes the application more secure, 


scalable, and manageable. 


С. СОКВА 


The Common Object Request Broker Architecture (CORBA) is used by a wide 
spectrum of the computer industry for creating distributed object systems. Object 
Management Group (OMG), an international non-profit consortium that includes more 
than 800 company members from all over the world, sets CORBA standards and 
specifications. One third of these members come from outside the United States. 
Microsoft is not a member of this consortium because it has its own proprietary product 
for distributed object systems called Distributed Component Object Model (DCOM). 
OMG does not produce software; it only defines specifications and makes them freely 
available for implementation to any interested party. Member companies meet frequently 
to reach a consensus on the specifications. Software that adheres to these standard 
specifications can interoperate with other software that meets the same standard. 

CORBA objects can live anywhere on a network, where they can discover each 
other and interoperate on the object bus. Remote clients can access these objects via 
method invocation. The location of any CORBA object is transparent to the client; these 
objects can be in the same process or sit on some other machine across the network. The 


client does not need to know how the server object is implemented. What the client needs 
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to know is only the published interface to that object. Therefore, the client misht be 
implemented in Java while the server is implemented in some other language, such as 
C++, Smalltak, or Ada. The interface is written in a neutral Interface Definition Language 
(IDL) that defines a distnbuted object’s boundanes. IDL makes all the objects that reside 
on the CORBA bus operating system and language independent. (Orfali, 1998, pp. 3-6) 


1. CORBA Architecture 


The OMG first published the Object Management Architecture Guide (OMA 
Guide) in 1990. It was revised 1n1992 with additional details added in 1995. 
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Figure 20. Object Management Architecture 


Figure 20 shows the four major parts of the architecture: 


• Object Request Broker. 


э CORBAservices. 
ə CORBAfacilites. 
ә and Application Objects 
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а. The Object Request Broker (ORB) 


The ORB forms the object bus that enables objects to transparently send 
requests to-and receive responses from-other objects located locally or remotely. The 
ORB enables objects to discover each other at run time and invoke each other’s services. 
“Тп theory, CORBA is the best client/server middleware ever defined. In practice CORBA 
is only as good as the products that implement it.” (Orfali, 1998, pp. 7-8) 


(1) ORB Benefits 


According to Orfali and Harkey (Orfali, 1998, pp. 8-9), the 
CORBA ORB provides the following list of benefits: 


• Static and dynamic method invocations. ACORBA ORB 
provides the ability to either statically define the method 
invocation at compile time, or dynamically discover them at 
run time. Static invocation provides strong type-checking 
whereas dynamic invocation provides more flexibility. 


* High-level language bindings. This benefit provides the 
user with the means to use a high-level programming 
language of his choice, yet the user is able to access server 
objects, regardless in which programming language the 
objects are written. 


• Self-describing system. The ORB maintains an Interface 
Repository that contains the descnption of all the functions 
a server provides. Clients use this metadata to generate 
code “on-the-fly”. 


• Local/remote transparency. An ORB can run on a single 
machine or on multiple machines ini” onnected with 
CORBA Internet Inter-ORB Protocol (IIOP). In either case, 
a CORBA programmer does not have to be concemed 
about “transports, server locations, object activation, byte 
ordering across dissimilar platforms, or target operating 
systems — CORBA makes it all transparent’ (Orfali, 1998, 


p 
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• Built-in security and transactions. The ORB includes 
context information to handle both secunty and 
transactions. 


• Polymorphic messaging. a method invoked on objects has 
different effects depending on the object receiving it. 


• Coexistence with existing systems. Using CORBA IDL, 
the user can wrap existing code to look like an object no 
matter how it was implemented. (Orfali,1998, pp. 7-9) 


(2) The Structure of CORBA 2.0 ORB 


The core ORB provides the facilities required to write distributed 
applications using different programming languages and operating systems. The basic 
function of the ORB is to provide the client with the facilities required to send requests to 
server objects and to get responses back. Figure 21 shows client and server interaction 
through the ORB. The following is a brief discussion of the various parts that comprise 
the ORB. 
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Figure 21. The Structure of CORBA 2.0 ORB (Orfali, 1998, p.11) 
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Client IDL Stubs: These stubs provide the client with the 
required interface to invoke statically services on the 
corresponding servers. IDL is used to generate both client 
and server stubs. 


Dynamic Invocation Interface (DID: A client can 
dynamically access the metadata in the Interface repository, 
discover its methods, and invoke these methods at run time. 
Static invocation provides strong type-checking at compile 
time which helps in discovering errors during development 
and making the application more robust, whereas the DII 
provides more flexibility. 


Interface Repository APIs: The ORB is a self-describing 
bus which maintains a repository that contains the 
descriptions of all registered interfaces. Clients mainly use 
this repository for dynamic invocation of methods on object 
servers. 


ORB Interface: This consists of APIs to some services that 
can be used by an application, such as converting an object 
reference to a string. 


Object Adapter: Provides an environment to instantiate 
server objects, assign them object IDs, and register them 
with the implementation repository. 


Server Static Skeleton: Provides an interface for statically 
accessing server objects. 


Dynamic Skeleton Interface (DSI): Corresponds to the 
clients DUI. These services handle clients? requests by 
finding the objects that offer their requests. DSI is useful in 
helping differently implemented ORBs that have no 
previous knowledge of each other, to interoperate. 


Implementation Repository: This repository consists of 
the information about the objects a server supports. 


(3) General Request Flow 


Clients make requests and the server objects act on them. Henning 
and Vinoski describe the request flow from the client application, through the ORB, and 


up to the server application in the following manner (Henning, 1999, pp. 16-17): 


о The clients either make a request using static stubs or using 
the DU. Either way, the request is directed into the ORB. 


> The ORB on the client side sends the request to the ORB on 
the server side. 


• The ORB core on the server dispatches the request to the 
object adapter. 


ө The object adapter further dispatches the request to the 
servant that implements the target object. 


+ After the request 15 executed, the servant returns the 
response to the client. 


There are different styles of CORBA requests (Henning, 1999, p. 


ue 
• A synchronous request: the client blocks while waiting for 
a response. 
• A deferred synchronous: the client sends a request, 


continues processing, and later polls for the response. 


• A oneway request: the client sends a request that may not 
be delivered to the target object and no response is allowed. 


• Future version asynchronous requests: allows the clients 


and server who are occasionally connected to communicate 
with one another. 


b. CORBAservices 


CORBAservices are useful system-level utilities that augment or 


complement the functionality of the ORB. These services provide the application 
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developer with the ability to manage, store, create, name, and locate objects. The 


following is a list of the more important services: 


• Naming Service: provides the ability to find an object, given its 
name. 
• Event Service: allows a client or a server to send a message, or 


event, to any number of receivers that registered their interest in 
specific events. This service introduces the notion of event 
channel; an event generator sends events to this channel and the 
event receiver receives the events from this channel. 


• Security Service: provides a framework to protect objects or 
groups of objects. The service addresses identification and 
authentication, confidentiality, and non-repudiation. 


• Concurrency Service: provides a locking mechanism to control 
the access to an object on behalf of either transactions or threads. 


> Property Service: provides operations to associate properties with 
any object. | 
° Transaction Service(OTS): provides two-phase commit 


coordination to control the commitment and abortion of 
transactions. These transactions may span multiple databases, of the 
same or of the different types. 


• Trading Service. This is an enhancement of the naming service 
which allows objects to be registered with a set of properties and 
then searched for by specifying constraints over these properties. 


e Relationship Service: allows the construction and management of 
relationships between objects that know nothing of each other. 


• Query Service: allows query operations to be executed against a 
collection of objects. This service is based on SQL3 and OMG 
Object Query Language (OQL). 


• Persistent Objects Service: defines a framework for how the 
communication between a database and an object should be. It deals 
with storing and restoring this object to and from the database. 


54 


• Externalization Service: provides a mechanism for copying an 
object to another location. Externalization means recording the 
state of an object in a stream of data that can be saved or 
transferred across the network. Reversing the process, which is 
called internalization, restores the externalized object. 


• Life Cycle Service: provides interfaces that allow objects to be 
created, moved, copied, and deleted from the ORB. 


• Licensing Service: allows a server to determine whether a 
machine on which it is running is licensed to run the software or 
not. 


El CORBAfacilities 


Whereas CORB Aservices provide utilities for individual objects or groups 
of objects, CORBAfacilities provide higher level support for applications. There are two 
types of CORBAfacilities: horizontal CORBAfacilities which can be used by virtually 
every business, and vertical CORBAfacilities that standardize some specific business 


areas. 
2 GIOP and IIOP 


General Inter-ORB Protocol (GIOP) defines a standard for sending ORB requests 
over some low-level communication protocol. GIOP was designed to work over TCP/IP, 
but could be used over Novell’s IPX or a future protocol. The Internet Inter-ORB 
Protocol (HOP) is the implementation of GIOP over TCP/IP. TOP makes CORBA 2.0 
ideally suited for Internet-and Intranet-based applications. According to the CORBA 2.0 
specification, every ORB must implement the Internet Inter-ORB Protocol (ПОР) ог 
provide a half-bridge to it. A half-bridge is a module that translates between the internal 
protocol and the IIOP. This requirement ensures that ORBs from different vendors are 


able to interoperate with each other. 
9: Interface Definition Language 


Interface Definition Language (IDL) is a declarative language-neutral standard 
language used to define a CORBA object interface via which an object advertises its 


services. An IDL interface provides the ORB with the information required to pass 
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messages to and from the object and a transparent access to the object. Language 
independence gives application developers the flexibility to implement their applications 
with the programming language that suits their requirements. IDL provides the ability to 
use different languages in the same system. Moreover, existing legacy code can continue 
to be used by creating an IDL wrapper for it. This wrapper will make the legacy code 
appear as a distributed component on the object bus. A number of IDL mappings exist to 


some languages, such as C++, Ada, and Java. 
а. The Structure of IDL 


IDL separates the specification of an object from its implementation. It is 
used to define an object’s attributes, services, parameters, types, and exceptions. Figure 
22 shows the structure of an IDL file. 


Define a naming 
MODULE < IDENTIFIER> context 


{ 


<type declaratıons>; 
<constant declaratıons>; 
<exception declarations>; 
Define a CORBA 
interface <identifier> [:<inheritence> class 


<type declarations>; 
<constant declarations>; 
<attribute declarations>; 
<exception declarations>; 
Define a method 
[<op_type>]<identifier> (<parameter>) 


[raises exception][context]; 





Figure 22. The Structure of a CORBA IDL File (Orfali, 1998, p. 420) 


The following 1s a brief discussion of the major elements that constitute a 


CORBA IDL file: 
• Modules: a module ıs a construct that provides a namespace that 
groups logically related IDL definitions. This construct 1s similar to 
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a package ш some other languages; for example, in Java, once an 
IDL file ıs compiled a module ıs mapped to a Java package. An 
IDL module introduces an additional level of hierarchy in the IDL 
namespace. 


• Interfaces: It defines a set of operations that can be performed on 
an object. An interface ıs sımilar to a class definition, but without 
an implementation. IDL interfaces support multiple inheritance and 
can declare one or more exceptions. 


. Operation: CORBA IDL defines the methods that a client can 
invoke. A method definition, a signature, consists of the method's 
parameters and the method's return type. 


5 Data types: The accepted values of CORBA parameters, 
exceptions, attributes, and return values. 


ISO Latin-1 character for graphic characters, ASCII for NULL 


TRE or FALSE 
8-bit uninterpreted 
Any Expresses any IDL type 


Table 3. IDL Types (lewis, 1998, p. 61) 





















and formatting characters 


There are two categories of data types: basic built-in types and constructed 
types. IDL uses its basic built-in types and its constructs for virtually creating any desired 


data type. 
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b. Basic Built-in Types 
IDL’s built-in types are showed in Table 3. 
с. Constructed Types 


IDL defines some structured data types including strings, enumerated 
types, structs, discriminated unions, and sequences. For more details on these data types 


the reader may consult one of the IDL books listed in the references. 
4. CORBA/Java and the Web 


The Internet has created the potential for a high level of business growth because 
of its reachablility to new customers and for its drastic cost reduction of information 
distribution. The Internet makes it possible for suppliers and consumers to be located 
worldwide. Nowadays, the Internet is one of the major communication tools that connect 
individuals, businesses, educational, and governmental organizations. 

There are different models to develop multi-tier client/server applications that take 
advantage of the potential provided by the Internet. Some of these models are the 
following: HTTP, HTTP with CGI, and CORBA. HTTP-based client/server interactions 
are stateless; the client establishes a connection to the server, makes a request, waits for a 
response, and then the connection is closed. HTTP is designed mainly to distribute static 
content to a large audience. The Common Gateway Interface (CGI) makes the HTTP 
servers dynamic. CGI launches a new process to service each incoming client request. 
Thus, HTTP with CGI is slow and stateless which makes it unsuitable for distributed 
object applications. Many vendors attempt to get around the stateless nature of HTTP and 
CGI by providing some extensions, but some of these extensions are vendor-specific and 
platform-dependent, which does not naturally fit the heterogeneous nature of the web. 

Many applications require context state to be maintained across multiple client 
requests. CORBA clients have a fine-grained contro! over the server objects. Whereas the 
HTTP clients cannot invoke methods directly on the server object, the CORBA clients 
can. Moreover, CORBA clients can pass a large number of parameters and user-defined 
objects to the server objects. HTTP clients always instantiate a request and there is no 
means for the servers to call clients and notify them with asynchronous events. CORBA 


supports callbacks in which a client passes an object reference to the server and the server 
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later can invoke an operation on that object, so client and server objects can have a peer- 
to-peer relationship. 

Appendix E shows Orfali and Harkey’s rating for the major six Object Web 
technologies including CORBA/UOP, Microsoft’s Distributed Component Object Model 
(DCOM), Remote Method Invocation (RMI), HITTP/CGI, Servlets, and Sockets. For 
more details, the reader may consult with Orfalı and Harkey’s book listed in the 
reterences. (Orfali, о 


5: Summary 


CORBA is used for creating distributed object systems. CORBA objects can live 
anywhere in the network, where they can discover each other. CORBA clients and servers 
can reside on different platforms, operating systems, and networks and still be able to 
interoperate as long as they implement the same IDL. CORBA overcomes the stateless 
nature of the HTTP by enabling clients to have a fine-grained control over the server 
objects. CORBA objects have a peer-to-peer relationship where both client and server 
objects can invoke methods on each other. 

After this brief overview of the technological background material, the reader will 
be ready to read the design, implementation, and analysis of the IOTS prototype in the 
next three chapters. Readers seeking more details about this technology may consult one 


or more of the references provided. 
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IV. IOTS RELATIONAL DATABASE DESIGN AND IMPLEMENTATION 


In this chapter, we build the IOTS data model using the Semantic Object 
Modeling technique. Next, we transform this model into a relational database design. 
Finally, we implement our design and generate the database schema. This chapter consists 


of the following sections: 


ө Development methodology 
è Proposed relational model 
® Database implementation 


A. DEVELOPMENT METHODOLOGY 


The methodology advocated for the development of the data architecture of the 
IOTS is a three-step process. As shown in Figure 23, the steps of this process are as 
follows: 1) define objects/entities, attributes, and relationships, 2) develop the data model, 
and 3) transform the data model into a relational database schema. Although these three 
Steps are listed in a chronological order, there is no hard line that separates any two 
consecutive steps. The further we go in the development process, the we understand the 
requirements. Therefore, to get a satisfactory product, there is always a need to refine 
within our budget for resource usage and to consider the return of investment. 

The system requirements, discussed in Chapter II, are the main source of input to 
developing the relational database model. Theoretically, other major sources of 
information can be used, such as the following: 1) existing documentation, screens, 
reports, data files, 2) questionnaires, and 3) interviews with developers, programmers, 
administrators, and end-users. In this research, we build our model based on the following 
inputs: 

o The underlying assumptions about the system and the research’s objectives 

discussed in Chapter I. 


• The system requirements, as listed in Chapter IL. 


ә Our experience in developing and managing Inventory Ordering and 
Tracking Systems. This previous knowledge helped us achieve our goal of 
designing a modern IOTS prototype. We employed some of the most 
common business rules used by some of the inventory ordering and 
tracking systems in today’s business. We also utilized our knowledge of 
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existing legacy reports, forms, screens snap shots, and data files. However, 
in the case of developing a system that ıs not constrained to our underlying 
assumptions, the developers’ judgement and experience in the system 
under design will never replace the real stakeholders’ points of view. This 
judgement and experience would rather provide a complementary 
perspective. 


System Legacy Legacy Legacy 
Requirements Reports, Screen Data Files 
апа Assumptions\ and Forms Snapshots 


Refinement | A | 
Define Entities, Attributes, 


and Relationships 
Refinement 


Develop Data Model 


Refinement Develop the Relational 
Database Schema 





Figure 23. Data Model Development Methodology 


B. PROPOSED RELATIONAL MODEL 


In this section, we follow the methodology discussed above in order to develop 


the relational database schema. 


1: Define Entities, Attributes, and Relationships 


The first step in the development of the IOTS database model is to discover the 
candidate entities. These entities, at the enterprise level, are referred to as data subjects. 
The data subjects for the IOTS are listed and defined in Appendix F. Defining these data 


subjects ıs important to the development process. It ıs critical that all personnel involved 
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in this process agree on these definitions in order to avoid any possible future 
inconsistencies between the data model and the IOTS prototype. In order for the prototype 
to meet the stakeholders’ expectations, it must be built on a well-defined basis. 

After the data subjects were defined, a list of candidate attributes was defined and 
showed in Appendix G. Appendix H shows which attributes belong to which data subject. 
Data subjects that are marked as “Independent” can exist on their own, whereas 
“Dependent” data subjects will exist only if their parents exist. 

Finally, the relationships between the data subjects were identified and defined as 
shown in Appendix I. Defining the relationships between these data subjects is a 


necessary step for building the data model, as we will see in the next subsection. 
2: Develop Data Model. 


By using the data subjects, attributes, and relationships identified in Appendices F 
through I, we developed a data model using the Semantic Object Modeling (SOM) 
technique in order to provide a better conceptual understanding of the requirements. This 
data model is shown in Appendix J. 

The SOM technique is similar to the Entity-Relationship (E-R) technique in that 
both of these techniques facilitate the understanding and documenting of the user’s data. 
The principal difference between these modeling tools is that the E-R model considers the 
entities and their relationships the atoms of the data model whereas the SOM takes the 
concept of semantic object as basic. These semantic objects are a map of the “things” that 
the users consider important. The semantic objects are the smallest distinguishable units 
the user may want to process. These objects may be decomposed later into smaller parts 
in the DBMS (or application), but during the modeling process, these smaller parts are of 
no interest to the users. (Kroenke, 1999, p. 102) 


The IOTS data model consists of the following semantic objects: 


ө ITEM 

• CUSTOMER 
• INVENTORY 
• INVOICE 


э ORDERS 
• TRANSACTION 
• USERS 


э WAREHOUSE 
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The semantic data model should be self-explanatory, but we assume that some of 


the audience may not be familiar with SOM technique. Therefore, we take the discussion 


one step further and comment on two of these semantic objects, CUSTOMER and 
ORDERS, that are shown ın Figure 24. 
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Figure 24. CUSTOMER and ORDERS Semantic Objects. 


a. CUSTOMER 







The CUSTOMER semantic object encapsulates the necessary information 


about customers. Each customer is given a unique identification number; the model 


shows the attribute “CustomerID” marked with double asterisks to indicate uniqueness. 


Customers also can be identified with their names, but more than one customer may have 


the same name. The model reflects this possibility by marking the "CustomerName" with 
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a single asterisk to indicate that duplicate names are allowed. The numbers on the nght 
side of each attribute, object reference, or data group show minimum and maximum 
cardinalities. The model specifies “ResidenceAddress” as zero minimum cardinality 
whereas it specifies “ShippingAddress” as having a minimum cardinality of one; this 
means that the resident address 1s not required (optional) or can be null, but the shipping 
address must be provided for each customer. The "TelephoneNumber" takes one as 
maximum cardinality, which means that no more than one telephone number is allowed. 
Whereas the fax number can be null (not provided), the telephone number must be 
provided. Object references show relationships among semantic objects. The object 
reference, “ORDERS”, has the cardinalities (0,N) which indicates that a customer may 


place many orders but may not have placed any orders at all. 
b. ORDERS 


This semantic object encapsulates the necessary information about orders. 
Each order has a unique identification number that will be used mainly for tracking 


purposes. Figure 25 shows a sample order. 


Quick Supply Incorporation(QSI) 
Customer Order 


Order ID: FC-345-AB Order Date: 01/18/2000 
Customer Name: Alice Maher Order Time: 8:00 AM 
Item Number Description Quantity Unit Price Extended Price 
1239567-34 Sanyodal TV 24x24 1 $420.00 $420.00 
2345568-28 Vedio Model234 1 5220.00 5220.00 

Tax $ 44.80 


Total Due: $684.80 


Figure 25. Sample Customer’ s Order 


The reference object CUSTOMER, with (1,1) cardinalities, indicates that 
each order must be associated with one and only one customer. The reference object 
INVOICE, with cardinalities (1,1), indicates that each order must appear on one and only 
once invoice. Since it is possible for an invoice to contain more than one order, the 
INVOICE reference object is marked by a single asterısk. The reference object 
TRANSACTION, with cardinalities (1,1), indicates that each order must have one and 
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only one transactıon type. Each transactıon type requires slıghtly different handling; for 
example an order placed directly by acustomer would be handled ın a different way from 
an order placed by an LSM іп terms of payment. Customers must provide their credit card 
numbers, but LSMs do not have to pay at all ıf their warehouses belong to the QSI. The 


reference object, ITEM, is embedded in a group ¡tem called “Lineltem” as follows: 


Lineltem 1-N 


1-1 
ІТЕМ 


Quantity 1-1 
ExtendedPrice 1-1 


The ITEM reference ıs marked by double asterisks to indicate that the 
same item may not appear on the same order more than once. This reference object is 
also specified as (1,1) cardinality to show that each "Lineltem" must have one and only 
one ITEM associated with it. Moreover, the reference object was grouped in a group data 
item, "Lineltem" with (1,N) cardinality to indicate that a single order must have at least 
one "Lineltem" and can have many "Lineltems" as shown in Figure 25. The 
"StatusTrackInfo" keeps track of each status an order takes, as well as the time and date 
on which the status was assigned. It may also contain some explanatory remarks to 
inform the user why an order may have been deleted or canceled. For example, Figure 26 


shows one possible sequence of the states assigned to the order presented in Figure 25. 


Quick Supply Incorporation(QSI) 
Tracking of Customer Order 


Order ID: FC-345-AB Customer Name: Alice Maher 
Status Status Date Status Time Remarks 

Waiting 01/18/2000 8:00AM 

Booked 01/18/2000 4:00PM 

Shipped 01/19/2000 9:00AM 

Delivered 01/20/2000 5:00PM 


Figure 26. Sample Track of a Customer’s Order 


The ORDERS data subject keeps track of the users who performed each 
transaction (state change) by recording the user’s identification code along with every 


status change. Every status change must be associated with one and only one user. Figure 
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26 does not show the users who performed the status changes since the sample track in 
that figure is generated for the use of the customers. This kind of information is required 
for managers to track problems, and customers are not supposed to know the employees 


who took actions on their orders. 
3. Transform the Data Model into Relations. 


In this subsection, we followed the transformation methodology suggested by 
Kroenke, (Kroenke, 1999, pp. 163-185), to transform the semantic objects into relations. 


A semantic object may be mapped into one or more relations. 


ITEM ItemID, ItemDescreption, PartNumber, PurchasePrice, 


UnitOfPurchase, SalePrice, UnitOfSale, Taxableltem 


CUSTOMER CustomerID, CustomerName, ResAddrStreet, ResAddrCity, 
ResAddrState, ResAddrZip, ShipAddrStreet, ShipAddrCity, 
ShipAddrState, ShipAddrZip, TelephoneNumber, FaxNumber, 
EmailAddress, CreditCardNumber, CreditCardExpDate, 
CreditCardT ype 


INVENTORY ItemID-FK, WarehouseID-FK, Balance, ReorderLevel, 

ReorderQt 

INVOICE InvoiceID, InvoiceDate, InvoiceTotal 

INVOICE DETAILS | InvoiceID-FK, OrderID-FK 

ORDERS OrderID, OrderDateAndTime, TransactonCode-FK, Tax, 
TotalDue, CustomerID FK, InvoiceID-FK 

ORDERS DETAILS | OrderID-FK, ItemID-FK, Quantity, UnitPrice, ExtendedPrice 

ORDERS_STATUS OrderID-FK, StatusDateAndTime, UserID-FK, Status, 
Remarks 


TRANSACTION TransactionCode, TransactionDesc 
USERS UserID, UserName, UserAccessLevel 


WAREHOUSE WarehouselD, WarehouseName, WareA ddrStreet, 





































WareAddrCity, WareAddrState, WareAddrZip, FaxNumber, 
TelephoneNumber 






Table 4. The IOTS Relations 
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The following conventions are used: underlined attributes are primary keys or part 
of primary keys, foreign keys are extended with the postfix “-FK”, and relation names are 
capitalized. If a foreign key 1s used locally it is also underlined. There are three major 
steps in the transformation process, which are transformation, normalization, and table 


definition. 
a. Transformation 
The transformation process results in the relations shown in Table 4. 
b. Normalization 


The data model is subject to a refinement process that modifies, adds, or 
deletes entities or their attributes in order to reflect the current business environment. As 
the refinement process occurs, the data model should be continually normalized. The 
normalization is a process that breaks an entity into two or more to eliminate undesirable 
modification anomalies. There are two types of modification anomalies, which are 
deletion and insertion anomalies. A deletion anomaly exists when facts are lost about two 
logical entities if one single deletion is performed. An insertion anomaly occurs when 
data cannot be inserted in a logical entity. Relational theorists chipped away at the types 
of modification anomalies to which relations are vulnerable and defined five. normal 
forms which classify relations and provide techniques to prevent anomalies from arising. 
For our purposes, we validated the above relations through the first three normal forms. 
АП the relations satisfy the first normal form because they meet the basic definition of a 
relation. All nonkey attributes are dependent on all of the keys. Therefore, the data model 
meets the criteria for the second normal form. Lastly, the data model also satisfies the 
third normal form by having no transitive dependencies. 

There are still some possible improvements that can be made; here we 
mention one possible enhancement. The CUSTOMER table can be broken down into two 
or more tables. It currently contains the residential address, fax number, and email 
address which are all optional attributes; in most of the cases, the customer may not 
provide this information, which means space will be wasted if these fields are populated 
by null data. The same reasoning holds for fax numbers and email addresses. So a 
possible solution is to break down the CUSTOMER table into the following four tables: 
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2 CUSTOMER (CustomerID, CustomerName, ShipAddrCity, 
ShipAddrState, ShipAddrZip, TelephoneNumber, 
CreditCardNumber, CreditCardExpDate, CreditCardT ype) 


• CUSTOMER_RESADDR(CustomerID-FK, ResAddrStreet, 
ResAddrCity, ResAddrState, ResAddrZip) 


• CUSTOMER FAX (CustomerID-FK, FaxNumber) 


а CUSTOMER EMAIL (CustomerID-FK, EmailAddress) 


However, there are costs associated with saving space. Breaking down the 
CUSTOMER table into these four new tables will complicate application development, 
and database administration and maintenance. Therefore, to keep the system simple, we 
have decided to keep the CUSTOMER relation unbroken. 


с. Table Definition 


Appendix K defines the attributes, primary keys, and foreign keys for all 
of the tables generated from the transformation process. This appendix will be the major 
input to the physical database design to be discussed in the next section. Special attention 
was paid to the selection of the primary keys. They were mainly selected from the 
attributes listed in Appendix H. Sometimes, there was a need to add new attributes to this 
list in order to uniquely identify some relations. Selecting primary keys must be carefully 
planned since they will be used to access relations for manipulation, modification, and 
retrieval purposes. These primary keys are required to facilitate the generation of the 
queries and reports listed in Appendices C and D. Moreover, the selection of the 
candidate attributes and primary keys should consider the available data attributes in the 


legacy data files in order to facilitate the future data migration to the new system. 
С. DATABASE IMPLEMENTATION 


In this section, we implement the relational database design for the IOTS. We 
select the DBMS product, define the IOTS database structure, and lay out the IOTS 


database system structure. 
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Rn Selecting the DBMS Product 


Oracle8i was chosen as a target DBMS for building the IOTS database structure. 
Whereas building the IOTS data model, in sections A and B, was independent of any 
DBMS product, implementing the IOTS database structure must evaluate the DBMS 
product being used since not all vendors commit to the same standards and conventions. 
We do not claim that Oracle8i is the best DBMS product in the market and the QSI needs 
to consider other DBMS products and decide on the best one that fits its needs. Usually 
making such decisions should be based on a special cost-benefit analysis that takes many 
factors into consideration, such as cost, legacy database migration, expected load, other 
alternatives, vendor’s support, expected gains/loses, etc. This kind of study is outside the 
scope of this research. Oracle8i and its products represent an industrial-strength modern 
DBMS, and the following Oracle8i's strengths are very relevant to the QSI's objectives 


and requirements: 


• Oracle&i adopts the Internet computing model where the QSI looks to get 
the benefit of the World Wide Web. Oracle8i also supports Java, CORBA, 
and other object-oriented languages. 


• Oracle8i provides the security mechanisms required for the QSI to work in 
an open environment. 


• Oracle8i has a suite of administrative tools that help in providing database 
backup and recovery, database migration, and network administration. 
Powerful tools are also available to help in application development and 
deployment. 


• Oracle81 runs on different computer systems, which allows many choices 
of technology to the decision-makers in the QSI. 


• Огасіе8і supports all the following computing models: Host-based, 
Client/Server, Distributed Processing, and Web-enabled Computing, 
which gives the QSI the flexibility to switch from one computing model to 
another as needed, or to use more than one computing model at the same 
time. 


• Oracle8i supports the Object-Relational model. The QSI ıs adopting to the 
object technology by using Java and CORBA; choosing OracleSı will push 
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this object-onented trend further and help the QSI define objects in their 
IOTS database. 


2: Defining the IOTS Database Structure to the DBMS 


Oracle81 provides two principal ways, as shown in Figure 27, for describing the 
structure of the database to the DBMS. The first way is to construct a text file that 
describes the structure of the database via the Data Definition Language (DDL). The text 
file names the tables, defines the indexes, and describes constraints and security 
restrictions. The latter way is to use the Schema Manager tool provided by ORACLE. 
This tool uses a graphical means for defining the structure of the database. With the 
Schema Manager (SM), an authorized user can view the database in a way similar to how 
the Windows 95 Explorer views the file structure. The SM makes it easy to add, modify, 


and delete tables, indexes, columns, views, primary keys, and foreign keys. 
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Figure 27. Database Structure Definition Process 


In this research, we use the classical DDL approach. The data structure is defined 
in a text file as shown in Appendix L. This Appendix defines the tables, indexes, 


attributes, primary keys, foreign keys, and constraints of the IOTS database. 
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3. IOTS Database System Architecture 


There are different system architectures that are used for multi-user database 
processing, such as teleprocessing, client/server, file sharing, distributed, and network 
database systems. The IOTS is intended to work in a client/server environment. Unlike 
teleprocessing, which involves a single computer, the client/server computing involves 
multiple computers. Some of these computers process the application program and are 
designated as clients. Another computer processes the database and is designated as a 
server. By adopting the client/server model, we have decided that the IOTS database will 
be unified rather than distributed. Distributed database processing allows partitioning and 
replication. Adopting the distributed database approach will increase parallelism, 
independence, flexibility, and availability, but at the same time this approach means 
greater expense, complexity, difficulty of control, and nsk to security (Kroenke, 1999, pp. 
280 -—284). The choice between unified and distributed database processing was based on 
the nature of the QSI’s business. The QSI seeks cost reduction, desires a system that can 
be managed easily, and highly values the confidentiality of its customers’ records. 

In the client/server database system, the application programs are placed on the 
clients’ side and the DBMS and the operating systems are placed on the server. Figure 28 


shows the programs involved in a client/server database system. 


Application | Driver IOTS 
Programs Manager Database 


Client Computers Server Computer 





Figure 28. Programs in Client/Server Database Applications 


The driver manager intermediates the application and the DBMS driver. When the 
application requests a connection with the database, the driver manager determines which 
DBMS driver is requested and loads it into memory. The function of the DBMS driver is 
to receive requests from the application, and format and deliver them to the DBMS. It 


also receives the responses from the DBMS and formats them to the application. A layer 
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of communication will handle the sent and received messages between the client and the 
server. In the next chapter, we will see that the ORB handles this communication layer. 
We will also see that the client application program, shown in the above figure, is actually 
the application server that will handle the actual clients’ requests from the Web browsers. 
This application program will serve as the middle-tier between the clients and the 


database server. 
D. SUMMARY 


The IOTS database prototype was developed by using the requirements defined in 
Chapter II of this research. The development methodology advocated for the development 
of the data architecture is a three-step process. The steps of this process are: 1) define 
entities, attributes, and relationships, 2) develop the data model, and 3) transform the data 
model into a relational database schema. Oracle8i was used as a target DBMS for 
building the IOTS database structure. The IOTS database was designed to work in 
client/server multi-user data processing environment. In the next Chapter, we design and 


implement an application prototype that accesses the database already implemented. 


79 


THIS PAGE INTENTIONALLY LEFT BLANK 


74 


V. DESIGN AND IMPLEMENTATION OF THE IOTS WEB BASED 
APPLICATION PROGRAM PROTOTYPE USING CORBA AND JDBC 


In this chapter, we start by selecting an Object Request Broker (ORB) 
implementation from those available from different vendors. Next, we go through the 
application design process using the ORB that we selected. After that, we design and 
implement the prototype. Finally, we list and comment on some snapshots of the 


prototype. 
A. ORB SELECTION 


There are several ORB implementations available, each with different features. 
The ORB implementation that we used for the IOTS prototype was Visigenic Visibroker 
3.4 that implements the specifications of CORBA 2.0. The main advantage of this 
product is that it has a stable IDL-to-Java mapping. Moreover, a client with access to the 
server via the Web is able to download the ORB on the fly. Although the selected ORB 
implementation is by Visigenic, the prototype was constructed using ORB independent 
services. Thus it is possible for the IOTS prototype to run on different ORB 


implementations assuming these implementations are CORBA compliant. 
B. APPLICATION DESIGN PROCESS WITH VISIBROKER 3.4 


As shown in Figure 29, the design process must adhere to the following steps in 
order to implement CORBA servers and clients. We illustrate this development process 
by creating a very simple client/server application. Understanding this example will help 
in understanding the more sophisticated system prototype that we build later in this 


chapter. 


1. Perform Object Analysis and Design 


First, we need to identify the objects that provide the system functionalities. In 
this Client/Server sample, the client will query the server about its local time. The server 
will be listening for the client’s incoming requests and respond to the client with a 
message that contains the local time on the machine that the server is running on. In this 
example, the required service will be provided by a single object that we call TimeServer. 


This object will provide one single method that we call getTime(). This method will 


15 


return to the client with a message that contains the local time at the server. For example, 


when the client invokes this method on the TimeServer object, it will get a response that 


is similar to this message: "The time at the server 15: 10:20:35". 


1) Object Analysis and Design | 


2) IDL Interface Specification 


у 


3) ıdl2java 


5) Implement the Client 
compiler 


Client Stubs 


Client 
Application/Applet 


6) javac 
Compiler 


8) Run the Client 


Client Application/ 
Applet 





4) Implement the Server 


Server Skeletons 
Object 
implementation 


Application Server 


7) Run the Server 


Object 
S Implementation < 


Figure 29. The Steps of Client/Server Development 
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2: Write the IDL Interface Specification for the Identified Objects 


As we discussed ın Chapter III, the IDL interface is a contract that defines the 
services provided by an object to its potential clients. Clients are not concerned about 
how this interface is actually implemented. The following is the IDL file for the 


TimeServer object. This file 1s saved as Example.idl. 


module Example ( 
interface TimeServer ( 
string getTime(); 

J; 

р 


2. Generate the Client Stubs and the Server Skeletons 


In our prototype we used the Visibroker idl2java compiler for generating both of 
the client stubs and the server skeletons. If, for example, you wanted to ımplement the 
client in Java language and the server in C++, you would need to run both idl2java and 
1d12C++ compilers. Next, take the stubs generated by the idl2java compiler and the 
skeletons generated by the idI2C++ compiler and throw out the rest. In our example, we 
intend to implement both the client and the server with Java. So, we enter the following 
command: 

prompt> idl2java Example.idl -no_comments -no_tie 

The -no_comment parameter instructs the compiler not to generate comments in 
the generated files. The -no_tie indicates that we do not wish to use the tie mechanism т 


the server implementation. The compiler will generate the following files: 


э TimeServer.java: This is the Java interface for the TimeServer object. We 
must provide code that implements this interface. This interface extends 
the root object in the ORB implementation. The following is the code of 
this interface: 


package Example; 


ТА 


public interface TimeServer extends 
com.inprise.vbroker. CORBA. Object { 
public java.lang.String getTime(); 


} 


• TimeServerHelper.java: This Java class provides helper services to the 
TimeServer clients. For example, this class enables the clients to use the 
narrow function that casts CORBA object references into a TimeServer 


type. 


• TimeServerHolder.java: This class overcomes a Java limitation of 
passing parameters. Java natively only supports "in" parameters, but with 
the help of this class Java can pass “out” and “inout” parameters. 


> _st_TimeServer.java: This class implements the client-side stub for the 
TimeServer object. It performs marshaling and unmarshaling of 
parameters. 

^ .St TimeServerImplBase.java: The CORBA server-side skeleton for the 


TimeServer object is implemented in this class. One way to implement the 
TimeServer object is to extend this class. 


• _example_TimeServer.java: The goal of this class is to facilitate the 
TimeServer implementation. It contains the constructors and empty 
definitions for the methods defined in the Example.idl file. 


4. Add the Server Implementation Code 


The developer must provide the implementation of the methods advertised in the 
interface. In other words, the business logic of the published IDL-interface must be 
provided. The following TimeServerlmp! class shows how the TimeServer object is 


implemented by extending the skeleton class using the inheritance approach: 


import java.util.Date; 

public class TimeServerlmpl extends Example. TimeServerlmplBase ( 
public TimeServerlmpl(java.lang.String name) ( 

super(name); ) 


public TimeServerlmpl() ( 
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super(); } 

public java.lang.String getTime() { 

Date t = new Date(); 

return ("The time at the server is: " + t.getHours()+":" 


+ t.getMinutes() +":" + t.getSeconds()); 


} 
} 
The following code acts as a driver. The main function initializes the ORB, 


instantiates the Basic Object Adapter (BOA), exports the TimeServerImpl object to the 


ORB, and waits for incoming requests. 


//Server.java 

public class Server ( 

public static void main(String[] args) ( 

try { 

// Initialize the ORB 

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB. init(args, null); 
// Create the basic object adapter 
org.omg.CORBA.BOA boa = 
((com.visigenic.vbroker.orb.ORB) orb).BOA_init(); 
// Create the servant object 

Example. TimeServer time = 

new TimeServerlmpl("local Time"); 

// Export the newly created object to the ORB 
boa.obj is ready(time); 
System.out.println(" Msg from server.. time: " + 
time +" is ready"); 

// Ready to serve requests 

boa.impl_is_ready(); 


} 


79 


catch (org.omg.CORBA.SystemException ex) 

{ 

System.err.println("System exception in TimeServer"); 
System.err.println(ex); 

V/catch 

V/main 

V/Server 


5. Write the Client Implementation 


Before the client can use the services provided by the server, it must obtain an 
object reference to that server. There are various ways for the client to obtain this 
reference. In the following client implementation, we use the bind() method to obtain a 
reference to the TimeServer object, whereas in the IOTS prototype the CORBA naming 
service is used. The bind method 1s ORB-dependent, whereas the naming service is not. 
Therefore, applications that utilize the naming service: are much more portable among 


varous ORB implementations. 


// Client.java 

class Client { 

public static void main (String [] args) { 

try { 

// \nitialize the ORB 

System.out.printin("Initializing the orb"); 

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null); 
// Bind to the TimeServer object 

System.out.printIn("binding to the TimeServer Object"); 
Example.TimeServer time = Example. TimeServerHelper.bind(orb, 
"оса те"); 

// Get the time 


System.out.printin(time.getTime()); 


80 


} catch (org.omg.CORBA.SystemException ex) { 
System.err.printin("System exception in Client"); 
System.err.printin(ex); 

V/catch 

y/main 

V/Client 


6. Compile the Client, the Server, and the Server Implementation 


Classes 


In order for the compilation to be successful, the compiler must have access to the 


files generated in step three above. We use the JDK1.2.2 compiler and enter the following 


commands: 


prompt> javac TimeServerlmpl.java 
prompt> javac Server.java 


prompt> javac Client.java 


T Run the Server 


Before running the server, the Visibroker requires that the OSAgent service be 


running. The OSAgent provides location service to help objects that are using the bind() 


operation locate each other. The following two commands start the OSAgent and the 


Server: 


prompt> start/min OSagent -c 


prompt> java Server 


8. Start the Client 
The client is started by using the following command 


prompt> java Client 
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Е. DESIGN AND IMPLEMENTATION OF THE IOTS PROTOTYPE 


In this section, we first discuss the QSI’s business model, build the system 


architecture, design the system prototype, and finally implement the prototype. 
| Business Model 


Unless an accurate business model is built for the QSI, the results will be “garbage 
in, garbage ош.” Figure 30 lays out the overall picture of this model. The QSI holds 
stocks of different kinds in its main store. The main store forms a buffer between 
suppliers and customers. These stocks are replenished by deliveries from suppliers and 
they are reduced to meet demands from customers. In Figure 1, the local warehouses are 
considered the only customers of the QSI. Here, Internet customers are added. This new 
category of customers must be accommodated in order to meet the requirements of the 
system discussed in Chapter II. The inventory is held in stock in the main store to allow 
for operations to continue smoothly in spite of the uncertainty in supply and demand. The 
QSI struggles to make the stock holdings as efficient as possible. The QSI always needs 
to know what items to stock, when to place orders, and what quantity should be ordered. 
So, in addition to the IOTS, the QSI is running an Inventory Control and Management 
System (ICMS). There is no clear boundary between these two systems since in most of 
the cases they are interrelated. For example, the ICMS calculates the amount of stock that 


should be held in the main store, using the amounts ordered through the IOTS. 


SUPPLY DEMAND 
nn With uncertainty in 


Acting as a de 
= the quantities ordered 
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ordered 


Internet Local 
Customers Warehouses 





Figure 30. The QSI's Business Model 


2. System Architecture 


The system architecture defines the basic system components and the relationships 
among them. It depends on the nature of the business and the requirements that must be 
achieved. Figure 31 shows the IOTS basic architecture. The Figure shows different 
applications for different users. In traditional businesses, buyers interact with their sellers 
directly, and both interact with the operations and support groups. On the Internet, the 
main means of interaction among these parties is via applications that place their retained 
states in the IOTS centralized database. The three major components that make up the 


system's architecture аге 


• Customer Components 
• Local Warehouse Components 
• Seller Components and Servers 
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Figure 31. System Architecture 
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а. Customer Components 


The primary tool used by customers ıs the World Wide Web. The IOTS 
will be restricted to the browsers’ capabilities. We will see later how Java/CORBA can 
extend these capabilities to benefit the customer and to overcome some of the web 
browsers’ limitations. The customers’ applications will provide the following 


functionalites: 


• Customers will be able to log on to the system, browse the 
available products, populate an order form, and submit that order. 
The order form will provide the customer with the means of editing 
personal ınformation, such as shipping address, billing address, and 
payment method. Moreover, the order form will be easy to use and 
enable the user to adjust the item quantities. 


• The system will make it easy for customers to register and track 
their orders. 
» Walk-in customers who do not want to register will also be served, 


but they will have to enter all the required information, i.e. name, 
address, etc. every time they decide to buy. Order tracking service 
will be provided for registered customers only. 


b. Local Warehouse Components 


This category provides services to the Local Store Managers (LSMs) who 
will be using the Web browsers. We make this category separate from the ordinary 
customers since the LSMs will be given more authority. The IOTS is expected to provide 
them with additional functionalities; therefore, they need special client applications and a 
distinguished user interface that meets their needs. The following three services are some 


examples of the many services that will be provided to LSMs: 


ә LSMs will be able to track orders they place, either one by one, ог 
by viewing the final status on all orders placed within a date range. 


o LSMs will be able to view the inventory levels of their stores. Note 
that the inventory levels of all the local stores are stored in the 
IOTS centralized database. Therefore, local warehouses do not 
record their inventory levels locally. 
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• LSMs will be able to order reports from the CMO and be able to 
track these reports. 


б; Seller Components and Servers 


The seller or the merchant provides the core functionalities of the IOTS by 


running and maintaining the following components: 


. Transaction Server. The transaction server will keep track of all 
the transactions placed by the Internet customers and the LSMs. It 
will record what was ordered, how much was ordered, and who 
ordered it. This server will be running the IOTS application 
prototype that will provide the transaction service in the middle 
tier. More details about the application prototype will follow later 
in this chapter. 


• Database Server. This server will be running the DBMS and will 
enable the users to access the IOTS database. This database was 
designed and implemented in chapter IJ using ORACLE8i. 


+ Fulfillment Networks. This component will take care of packing 
and shipping orders. The seller has access to the transaction 
statements and can mark orders as fulfilled and send the 
appropriate notification to the customer. 


s Financial Networks and Payment Gateway. This group will take 
care of all the payment instruments in the system. For example, the 
sellers will connect the credit card agencies through the payment 
gateway in order to authorize the transaction and later to settle the 
payment. 


• Inventory Control and Management (ICM) Ne‘work. This part 
of the QSI is responsible for managing the inven: ry levels across 
all the warehouses. The ICM group decides what items should be 
stocked, when an order from the suppliers should be placed, and 
how much should be ordered. Inventory levels are controlled 
through a set of applications that run on the ICM Server. The 
connection to the suppliers is performed through the suppliers’ 
Gateway Server. 
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• Tax Server. In the United States, the buyer owes taxes to the state 
governments, counties, and localities (cities). There are over 6,000 
rules about sales tax and they change frequently (Treese, 1998, p. 
296). Figure 32 shows the required inputs for the Tax server to 
perform tax calculations. For the sake of simplicity, the IOTS 
prototype applies a fixed rate of seven percent on taxable items. 
However, in practice, the tax must be calculated in the right way; 
otherwise it will not be legal. Placing the Tax server on a stand- 
alone machine will make it easy to manage and maintain. without 
affecting the other parts of the system. 


Merchant Information 
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Product Information 


Tax Rules and 


Transaction Information Rates 





Figure 32. U.S Sales Tax Calculation (Treese, 1998, р. 296) 


• Operator Applications. This set of applications is used for 
configuring, maintaining, administering, and monitoring all the 
components that exists under the seller’s control. 


3. Prototype Design 


There is no clear cut wisdom on how to conduct the design process of a 
distributed system. Most of the design methodologies that we surveyed agree on two 
major steps. The first step ıs to start with the problem statements and divide the required 


functionalities among objects. The latter step is to define the services provided by each 
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single object and the ınteractions among them. This wıll ensure that the system satisfies 
the requirements and provides the expected services. 

In the design of the IOTS prototype, we use a “quick-and-dirty” procedure that 
goes side by side wıth the implementation ın order to get early feedback on whether our 
design is on the nght track or not. This works fine for a prototype which only covers a 
small set of the overall IOTS functionalities. In order to provide a complete design of the 
IOTS, however, a more formal design process must be followed; otherwise, with 
hundreds of objects it can quickly become complicated. Designing distributed 
applications is quite complex and even with the simple prototype we could not keep it 


consistent, structured, simple, and straightforward without performing these steps: 


з Define the user interfaces of the system to ensure that all of the IOTS's 
required services will be provided to the authorized users. 


• Pick one of these interfaces and generate different use cases. For more 
details on use-case analysis, the audience may consult with (Booch, 1994) 
or with (Blaha, 1998). 


• Define the object model. 


• Break down each single use case into one or more scenarios and use the 
sequence diagrams to illustrate how objects that were defined in the object 
model will interact in order to implement each scenario. 


• Write the Interface Definition Language (IDL) specifications. 
a. User Interfaces 


The IOTS is broken down into these various interfaces in order to ensure 
that it provides the functionalities that satisfies the requirements listed in Chapter II of 


this research: 

• Customers Interface. Used by customers to place and track orders 
over the Internet. It also provides the customers with the necessary 
services, ı.e. enabling them to modify shipping and billing 
addresses and giving them directions on how to use the interface 
and how to contact the sellers. 


. LSMs Interface. Used by LSMs to place and track orders for their 
warehouses. It also enables them to order and track reports from 
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b. 


the CMO. Appendix D shows a lıst of these reports. Moreover, 
using this interface, the LSMs will be able to perform the queries 
listed in Appendix C. 


Purchase Interface. This interface is used by the GSMs to place 
and track orders from the suppliers. 


Inventory Control and Management (ICM) Interface. The 
GSMs will use the ICM interface to control the inventory levels 
across all the warehouses. This interface wıll help the GSMs 
decide what ıtems should be placed ın stock, what ıtems should be 
removed, when to place an order, and how much to order. This 
interface will also be used to generate the various reports listed ın 
Appendix D. | 


Fulfillment Interface. Will be used by fulfillment group to help in 
packing the booked orders and to mark these orders as shipped 
when they go out. 


Payment Interface. This interface will help to authorize the 
transaction and to settle the payment later. Paid orders will be 
marked as "PAID." Paid orders will eventually be closed, removed 
from the database to save some space, and archived for later 
possible use. This interface will perform the billing. 


Other Interfaces. This includes operator interface and customer 
service interface. Operators use the operator interface to maintain, 
administer, and monitor the system. The customer interface is used 
to provide services to customers. For example, a customer may 
phone, inquiring about his order and a customer representative will 
use this interface to serve that customer. 


Use Cases 


Among the interfaces listed above, we chose to design and implement 


some of the functionalities provided by the LSMs Interface. In practice, the use cases are 
generated from the interactions with the end users. For our purposes, we analyze the roles 


of the LSMs and the requirements defined in Chapter II, and generate the following set of 


An LSM places an order. 
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• An LSM finds out about the status of an order. 


• An LSM finds out about the status of a group of orders within a 
date range. 


• An LSM adds an item to an existing order. 

• An LSM inquires about the available balance of a given inventory. 
• An LSM creates, adds, and modifies a customer record. 

• An LSM modifies the informatıon about hıs or her warehouse, like 


an address, telephone number, etc. 
• An LSM lists all the transactions made on a given inventory. 
• An LSM orders a report. 
• An LSM finds out about the status of an ordered report. 
e Object Model 


After the use cases are defined, the object model is developed. The basic 
objects in the system are defined and the interaction among these objects determined. The 
Unified Modeling Language (UML) 1s used to facilitate the design process. Figure 33 


shows a simplified object model of the IOTS prototype. 
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d. Scenarios and Sequence Diagrams 


The sequence diagrams illustrate how objects will interact in a specific 
scenario. Sequence diagrams make the developer visualize how the distributed objects 
will interact to execute a given scenario. Moreover, sequence diagrams will help the 
developers discover any mismatches between the clients and servers objects early in the 


design process. Finding such discrepancies at the beginning of the design phase will 


EI 


reduce the cost of fixing them and will reduce the possible bugs that may appear during 
the implementation. 

Each use case can be broken down into one or more scenarios and each 
single scenario can be represented with a sequence diagram. For example, the following 


are some of scenarios that were defined for the "An LSM places an order" use case: 


. An LSM places a valid order. 
° An LSM places an order for an item that does not exist. 


• An LSM places an order with quantity equal to zero or greater than 
the reorder-level. 
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Figure 34. The Sequence Diagram for Placing a Valid Order 
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° An LSM places an order on behalf of the warehouse. 


• An LSM places an order on behalf of a customer, and the LSM 
does not provide valid customer information. 


• An LSM submits an order with no items. 


° An LSM places an order for an item that has no available balance 
in the main store. 


2 An LSM places an order for an item that is no longer supplied. 


Figure 34 shows the sequence diagram for "An LSM places a valid order" 


scenario as an example. 
с. IDL Specifications 


The last step of the design process 1s to write the formal IDL specifications 
that will serve as a contract between clients and servers objects. We have briefly 
discussed IDL in Chapter II. The complete IDL specification file for the IOTS prototype 
is listed in Appendix M. 


4. Prototype Implementation 


The IOTS prototype is implemented as a three-tiered client/server application as 
shown in Figure 35. In Chapter II, we discussed the advantages of three-tiered 
applications over two-tiered applications. 

The first tier, the client, is the user interface for the LSMs, which will be running 
on the Web browsers. The second tier, the server, can serve both HTTP and CORBA. The 
server will encapsulate the business logic and interact with the client via CORBA/IIOP. 
CORBA objects will interact with each other using CORBA Object Request Broker 
(ORB), and they will talk to the third tier using SQL/JDBC. The third tier consists of the 
IOTS database that will be accessed by the CORBA objects. The IOTS database was 
designed and implemented in chapter IV of this research. CORB A/Java will be used to 


encapsulate most of the third-tier functions. 
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Figure 35. The IOTS in a Three-tiered Client/Server Architecture 


As shown in Figure 36, the IOTS prototype consists of the following three 


categories of components: 


• Client components 
• Transaction Server components 
• Database Server components. 


The third category was discussed in Chapter IV so we limit the discussion to the 
first two categories. Appendix O lists all the software components used in the 


development of the IOTS prototype. 
a. Client Components 


A Web browser downloads the HTML page that includes references to the 
embedded Java applets using the HTTP. The browser also downloads the required ORB 
classes. The HTML was mainly used to embed the client’s applet. In practice, the QSI 
may consider some other markup languages, such as the Extended Markup Language 
(XML), and the Standard Generalized Markup Language (SGML). For a comparison of 


these languages, the reader may refer to (Norman, 1998). 
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Figure 36. The IOTS Prototype Components 


The following is the source HTML code for the "index.html" file that we 
wrote to work in the IOTS prototype. The numbers in braces are not part of the code, and 


they will be used later to explain the applet's parameters: 


<HTML> 

<h1>Quick Supply Inc. </h1> 

<hr> <center> 

«APPLET CODE=lotsApplet.class WIDTH =550 HEIGHT=350> 

(1 <param name=org.omg.CORBA.ORBClass 
value=com.visigenic.vbroker.orb.ORB> 

(2) <param name=ORBgatekeeperlOR 
value=http://computerb: 15000/gatekeeper.ior> 


(3) param name=ORBalwaysProxy 
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value=true> 
(4 <param name=ORBservices value=CosNaming> 
<param name=SVCnameroot value=lotsNames> 
</APPLET> 
</center> 
<hr> 
</HTML> 


The above code contains some parameters. The first parameter forces the 
applet to download the ORB classes from the Web server. The second parameter 
indicates the port and the computer on which the Gatekeeper is running. The third 
parameter forces the client to use the Gatekeeper before it can access the CORBA objects 
on the transaction server. This parameter is used to enforce security and to increase 
performance. With this parameter, the ORB will not try to connect directly to server 
objects even when the server objects are reachable by the client. Therefore, the ORB will 
not waste time trying to connect to some unreachable objects. More information on the 
Gatekeeper will be provided under server components. The last parameter indicates that 
the applet requires the CORBA naming service to find the server objects and that the 
root-naming context is "IotsNames". 

Since our prototype was designed with JDK versionl.2.2, the Web 
browsers that contain an older JVM will not be able to execute our prototype. So, clients 
need to download the JVM plug-in from Sun’s Javasoft Web site. We have converted the 
above HTML code using the HTMLConverter from Sun. The HTMLConverter adds 
some tags to the code. These additional tags will enforce Web browsers to use the JVM 
plug-ins that you downloaded instead of the Web browser's baked-in JVM. If the required 
plug-ins were not up-to-date the client will be guided to the Web site where the required 
version can be downloaded. After that, we designed a Web page with Microsoft Front 
Page 98 and embedded the converted applet in it. The final HTML code is shown in 
Appendix N. 

The JotsApplet.class references the JotsLSMsBean.class that will initialize 
the orb and return a reference to a server object. The connection between the client applet 
and the server object will be performed over HOP and not over HTTP. This connection 


shows the beauty of the Object Web. Java is necessary, but not sufficient for creating the 
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Object Web. It needs to work side by side with CORBA to achieve this goal. The client of 
the IOTS prototype is packaged into a single HTML page (index.html) that contains 
several components. Interestingly, clients will be able to interact with server objects by 
clicking any of these components without switching page’s context to obtain each 


response. 
b. Transaction Server Components 


The middle tier contains the following components: 
• НТТР Зегуег 


As mentioned earlier, the HTTP Server will enable clients to download the 
HTML pages, the referenced Java classes, and the ORB classes. In the IOTS prototype, 
Microsoft Internet Information Server (IIS) was used to provide HTTP service. In 
practice, the QSI may need to consider performance, security, scalability, and other 


related issues before selecting the HTTP server. 
a Gatekeeper 


Web browsers impose the following restrictions on Java applets: 


• Applets are only allowed to connect to the host from which they 
were downloaded. 


+ Applets are only allowed to accept connections from the host from 
which they were down loaded. 


The Gatekeeper is used to provide a way that works with these restrictions. 
To get around the first restriction, the Gatekeeper acts like an HOP firewall proxy that 
forwards any calls from the applet to the target object. The second restriction 1s also 
handled by the Gatekeeper. The ORB sets up a special connection between the applet and 
the gatekeeper. The Gatekeeper uses this connection to forward the callback from the 


server object to the client. (Inprise, 1999, p. 2-2) 


o lotsServer.class 


oT 


This class implements the main method for the server. First, it initializes 
the ORB and creates a new lotsDispenser object. Next, it registers this object with the 
ORB. After that, the newly-created lotsDispenserlmpl object is registered with the 
naming service. Finally, the server waits for incoming requests. The source code for this 


class and all other Java classes 1s provided in Appendix P. 


• IotsDispenserImpl.class 


This class 1mplements the IotsDispenser interface. It was reused from 
(Orfali, 1998, pp. 944-946) after we changed it slightly. It creates a pool of IotsMedImpl 
objects and stores their references in an array of IotsStatus objects. Each IotsMedImpl 
object is registered to the ORB. 

This class uses its reserveObject method to reserve one of the objects from 
the object pool to the client. The releaseObject method is used to release the object from 
the client and return it to the pool. Objects are located to clients on demand. Each object 
runs in its own thread and maintains a live connection with the database. Therefore, 
once one of these objects is allocated to a client, the client does not have to wait for a 
connection to be established. This will increase the performance and will make it possible 


for the client to be served without much delay. 


ө IotsStatus.class 


The IotsDispenserImpl will contain an array of these objects. IotsStatus 
contains two fields: the first is a reference to the server object and the second is a flag that 
indicates whether and object is reserved by a client or not. If an object is reserved to a 
client, other clients will not be able to access it, they will reserve another object from the 


pool, instead. 


• IotsMedImpl.class 


This class creates a new IotsDBClass object that is connected to the 
database in the third tier via JDBC. It implements all the client's required methods. Each 


one of these methods corresponds to a method implemented in the IotsDBClass object. 
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Ф IotsDBClass.class 


This class encapsulates all the methods needed to interact with the 


database in order to provide the client with the required service. 


> Driver Manager and JDBC Thin Driver. 


The functionalities of these drivers were discussed in Chapter IV. The 
ORACLE thin driver was used to maintain a JDBC connection between the lotsDB Class 
object and the IOTS database server in the third tier. 


D. SYSTEM OPERATION SCENARIO 


The steps listed below should be followed so that the IOTS can provide services 


to clients: 


ө Install Java and Visibroker ORB on the machine that will host the 
СОВВА server. 


• Start the Visibroker OSAgent. This tool is used transparently by the 
naming service. In windows NT, the OSagent can be started automatically 
by adding it to the system services or by typing the following command: 
prompt» start/min osagent -c 

, Start the CORBA naming service by entering the following command: 
prompt> start /min vbj 
-DORBservices=CosNaming 
-DSVCnameroot=lotsNames 
-DJDKrenamingBub 
com.visigenic.vbroker.services.CosNaming.ExtFactory lotsNames 
%VBROKER_ADM%\cosnm_dir\lotsNames.log 

à Start the Gatekeeper by entering the following command: 
prompt» start/min gatekeeper 

з Start the server by entering the following command: 


prompt> start/min vbj 
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-DORBservices=CosNaming 


-DSVCnameroot=lotsNames lotsServer <num_of_ con_objs> 
The num_of_con_objs ıs the number of live connection objects that must be ready 


in the connection pool in order to serve customers. The default of this parameter is four 


Install the HTML files and the Java applet classes on the Web server 


Clients can access the server by entering the appropriate URL in their 
browsers. For our IOTS prototype, the URL is 
http://computerb.otoom/thesis/index.htm. 


The following are some snapshots obtained after running the IOTS prototype. Figure 


37 shows the logon screen on which authorized LSMs are authenticated to the system 
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Figure 37. Logon Form 
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Because some of the ınformation about customers, 1.е. addresses, credit card types 
and expiration dates, electronic mail addresses, and phone and fax numbers change 
frequently, LSMs use the form shown in Figure 38 ın order to keep customers’ records up 


to date. 
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Figure 38. Customer Form 


LSMs use the form shown in Figure 39 in order to keep their warehouses’ 


identification records up-to-date. 
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Figure 40. Inventory Levels Form 


The form shown in Figure 40 enables LSMs to inquire about the inventory levels. 


The Form shown in Figure 41 enables LSMs to place orders. An LSM can choose 
to place an order for a customer or to place an order for the local warehouses by choosing 
the appropriate transaction code. The form below shows an order placed by a LSM for a 
customer. The LSM is able to select from the items offered for sale, add to and delete 
from a shopping cart, adjust ordered quantities, and submit the order once ready. After 


submitting the order, the LSM will be provided with a unique number that can be used for 


tracking purposes. The LSM will pass this number onto the customer. 
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Figure 41. Place Orders Form 


Finally, Figure 42 shows the form via which an LSM can track a single order by 
entering the exact order identification number, or a group of orders by entering the date 
range in which these orders occurred. The figure shows a list of the orders placed within a 
date range along with the final status on each order. The LSM can obtain a more detailed 
track by selecting the order identification number. A detailed track for the order number 


“12459” ıs shown as an example. 
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Figure 42. Track Orders Form 


Е. SUMMARY 


This Chapter overviewed the CORBA application design process using Visibroker 
3.4 with an illustrative example, defined the QSI’s business model, laid out the system 
architecture and various user interfaces, designed the prototype by utilizing use-case 
analysis, generated the necessary UML and sequence diagrams, implemented the 
prototype as a three-tiered client/server application using CORBA/Java, and finally listed 


and commented on some snapshots of the prototype. 


104 


VI. ANALYSIS AND CONCLUSIONS 


This chapter addresses the research objectives and research questions that were 
stated in Chapter I of this thesis. It also lists some of the possible benefits that can be 
gained from adopting the IOTS over maintaining the, status quo. Finally, it presents the 


conclusions and recommendations. 


А. ACHIEVEMENT OF RESEARCH OBJECTIVES AND QUESTIONS 


1. Requirements of the New IOTS Database and Application Program 
for the QSI 


Chapter II was completely dedicated to listing the requirements of the new IOTS. 
In order to determine these requirements, we started by analyzing the current situation. 
Next, we addressed two major categories of problems that the current IOTS suffers from. 
The first category consists of the problems imposed by the closed platform and operating 
system dependent environment that the IOTS operates in. The latter category involves 
problems related to the way in which the IOTS was designed and implemented. 

The major problem that motivates reengineering the current legacy IOTS is its 
weak supply chain. In the current system, customers are not able to place and track their 
orders, the QSI is not connected to the suppliers in real-time, and various inventory 
ordering and tracking activities cannot smoothly interoperate with each other at a system- 
wide level. Supply chain management integrates both sellers’ and buyers’ processes to 
increase the system’s responsiveness and competitiveness. The new IOTS will be able to 
benefit from some of the revolutionary advancements in technology, namely the 
emergence of Web-based technology, enhancements in the client/server architectures, 
declines in the price of personal computers, and existence of platform-independent 
programming languages. 

We discussed the business drivers that call for the reengineering process, justify 
the costs and nsks of instantiating this process, and provide the major source of 
motivation to this research’s proposed solution. The requirements were listed to support 
these business drivers and motivate a solution for both of the problem categories already 
mentioned. The IOTS prototype was built based on these requirements. The question that 


was in mind during the design and the implementation of the IOTS prototype is how 
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implementing these requirements will contnbute to the solution of the problems that were 
identified. Another goal was to figure out what additional benefits can be gained from 


adopting the modern technology, over just solving the existing problems. 
D Interoperability, Platform and Operating System Dependence 


In chapters IV and V of this research, we designed and implemented an object- 
oriented web-based Inventory Ordering and Tracking System (IOTS) prototype based on 
the OMG’s CORBA. Our goal was to illustrate how CORBA/Java can be used to add 
value to the business and to address the challenge of interoperability. The challenge of 
interoperability is one of the most critical problems facing enterprises that want to shift 
their business to the open market rather than be restricted to a particular operating system 
or a specific platform. Enterprises need to avoid lock-ins to particular vendor's products 
and need to develop systems that can work and interact with each other efficiently in the 
open environment. We achieved our goal by using platform-independent object-oriented 
programming languages (Java and CORBA) as a backbone that easily connects different 
applications running on different platforms and different operating systems. 

As shown in Figure 43, in the distnbuted object model offered by CORBA, the 
client cannot tell whether the target object is local or remote. For example, the IotsApplet, 
lotsDBClass, and IotsMed client/server objects appear to a client as if they reside on its 
machine even though these objects exit on different machines and run on top of different 
operating systems. The user may be aware of where the target object actually resides, but 


this does not affect the invocation. Therefore the IOTS client and servers implementation 


may 
ө operate on different vendors’ ORBs; 
~ exist on different operating systems and platforms; 
. work across multiple heterogeneous networks; 
• be written in different programming languages, 
• and still interoperate as long as clients and servers are implementing the 
same IDL. 
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IotsApplet IotsDBClass 





Figure 43. ORB-to-ORB Interoperability 


3. Scalability 


The three-tier approach adopted by the IOTS prototype allows the QSI to install 
additional application and database servers as demand increases. As the IOTS grows in 
size, complexity, and functionality it becomes more necessary to address the issues of 
load balancing, fault tolerance, and managing components. No distributed system will be 
able to scale without managing memory, connections, and threads. In the IOTS prototype 
implementation, we mainly addressed the management of connections. The default 
threading policy was used, and little more was said about memory management. 

Memory management must achieve two major goals. The first is to ensure that the 
server never leaks memory; that is, once an object is instantiated, it will be eventually 
freed. The latter is to limit the amount of memory used by a server process. This is 
accomplished by deactivating idle servant objects. A large number of customers accessing 
a single server object can be a problem. The following are three different approaches to 
solving this problem: replicating servers, connection closure, and concentrators. (Slama, 
9: рр. 22885) 

In Chapter V, the Dispenser object was used to assign each customer a single 
connection object from a pool of live connection objects. This object 1s released when the 
customer is no longer using it in order to make it available for other customers. Either the 


client or the server can perform the connection closure. The IOTS prototype gives the 
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client the right to decide the connection closure. The connection is closed and the 
connection object is released and returned to the connection pool when the client closes 
the application. 

The IOTS still needs to address the issues of load balancing and fault tolerance. 
Load balancing deals with distributing the application load over many servants on many 
hosts. Fault tolerance is the measure of the degree an application can continue to operate 
in the presence of failures in hardware/software/OS, physical communication, 
applications, or a failure due to client-server mismatches. The IOTS prototype provides a 
limited level of fault tolerance by using the exception classes of Java and CORBA. When 
an exception occurs, the prototype tries to handle this exception appropriately in order to 
prevent the whole application from crashing (1.e., continue operation in a degrade mode). 

The IOTS is built on top of the Visibroker’s ORB. This product also provides 
some fault tolerance features. In case a connection between a client application and the 
object implementation fails because of a network error, Visibroker will automatically 
attempt to re-bind to the server process or a replica of that server. If one of the 
Visibroker’s OSagents becomes unavailable, all object implementations registered with 
that agent will automatically be registered with another agent. 

The issue of scalability in a distributed object environment requires specialized 
Studies; our purpose here 15 to highlighted the major issues. One of our recommendations 
is to build a benchmark that tests how scalable the IOTS prototype is when a large 


number of customers are accessing the CORBA server concurrently. 


4. What are the Possible Benefits and Advantages of this Program from 
Both the Technical and Management Perspectives? 


The following are some of the possible benefits if the proposed IOTS is adopted: 


• The QSI is no longer locked into a particular vendor’s products. They 
can choose their Hardware and Software from among multiple vendors. 
This will make the procurement process easier and more cost effective. 
Clearly, having multiple alternatives to choose from enables decision- 
makers to select the alternative that best suites the enterprise’s needs 
within budget constraints. 


• The QSI can integrate various object components. With the proposed 
IOTS, it 1s easy to integrate purchased object components that model 
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common knowledge in some business fields and combine them with 
modules written in-house. For example, the QSI can purchase the 
executable object implementation along with the IDL file from a vendor. 
This code is installed on the ORB on the application server. QSI can then 
write its own client in the language it prefers, independent of language the 
vendor used to implement the purchased object components. 


Performance. Although we used Java to implement both the client and the 
server in the IOTS prototype, clients and servers do not have to be 
implemented in the same language. This makes it possible to use each 
application language in the place where it provides the best performance. 
For example, Java is very suitable to implement GUIs and Applets so it is 
one of the best choices to design clients that use the Web. C++ on the 
other hand can be used to implement the server in order to provide 
services that require high performance. 


The management of connections, which is used by the IOTS 
prototype, gives another enhancement to the system’s performance. 
Objects are reserved to clients on demand. Each of these objects run in its 
own thread and maintains a live connection with the database. Therefore, 
once one of these objects is allocated to a client, the client does not have to 
wait for a connection to be established. This will increase the performance 
and permits the client to be served without much delay. This design, 
however, increases the overhead and may overload the system if it is being 
concurrently accessed by a large number of customers. Again, this 
scalability issue must be handled and the load must be balanced. 


Object Web. By adopting the proposed IOTS, the QSI will be denving 
benefits from the Object Web. The IOTS prototype client is packaged into 
a single HTML page that contains several components so that clients can 
interact with server objects by clicking any of these components without 
switching the page’s context to obtain each response. Thus there is no 
need to generate dynamically an HTML page for each response. Moreover, 
the Object Web makes it easy for server objects to callback the client 
applet. This feature will enable the server to keep the + ient up-to-date 
with the most recent information. 


Reachability. In the closed environment, the QSI has problems 
establishing connections with its suppliers, and it supports a limited 
number of customers. In the open environment, the IOTS enables the QSI 
to interoperate with the suppliers and customers from all over the globe. 
Clearly, increasing the number of customers and the market share 
promises the QSI a more profitable business. There are other non-technical 
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factors, such as business management, that also play a role ın determining 
the profitability of business. 


• Information Infrastructure. As discussed in Chapter П, the 
communication among applications has typically been made through batch 
processes. This lack of an adequate information infrastructure resulted in 
redundant data being maintained by different systems and led to a waste of 
computer resources, manpower, and time. In the proposed IOTS, the 
communication between all the applications that provide the overall 
system functionality is performed in real-time, which means that the 
current system provides more adequate information infrastructure, 
eliminates potential occurrence of errors, and maintains data integrity. 


• Cost Reduction. The potential benefits previously mentioned suggest that 
the QSI might be more profitable by adopting the new IOTS over the 
closed system it currently operates in, but it 1s hard to judge by intuition 
alone whether the new IOTS will provide cost reduction or not. There will 
be new opportunities for the QSI if it becomes available on the Web. The 
procurement cost is likely to go down since the QSI will have many 
choices of technology and will not be locked into any particular vendor's 
products. Replacing the mainframe with desktop computers also promises 
additional cost reductions. The cost of maintaining the mainframe is very 
high and performing the maintenance requires a high-level of expertise 
usually not available in house. This often must be outsourced, whereas the 
maintenance cost of desktop computers 15 far less expensive and can be 
performed in house. Also it can be performed remotely and automatically, 
which significantly contributes to cost reduction, at least in terms of 
manpower. Although putting the power of a large mainframe computer on 
a desktop is possible, the cost of administering desktop computers that are 
each configured slightly differently might be significant and outweigh their 
advantages. The expected savings may not materialize because of 
unexpected hidden costs; the savings in desktop hardware acquisition are 
often offset by high annual operating costs for additional labor required to 
administer and maintain the network. The cost of migrating the current 
legacy system and the conversion of the IOTS database to work in the new 
environment may also offset the expected benefits. 


ол 


What is an Appropriate Design for the New IOTS Database and 
Application Program? 


Chapter IV used an iterative methodology to generate an appropriate design for 


the IOTS database. This methodology consists of the following three steps: 1) define 
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entities, attributes, and relationships, 2) develop the data model, and 3) transform the data 
model into a relational database schema. The design was iterative since there is no hard 
line that separates any two consecutive steps. The further we go in the development 
process the better understanding of the requirements we get; therefore, there is always a 
need to go back in order to enhance our design. 

In Chapter V, we stepped through the design and the implementation process of 
the IOTS prototype. We first used Visibroker to go through the application design process 
with the help of an illustrative example. Next, we designed the IOTS prototype using use- 


case analysis and the Unified Modeling Language (UML) notation. 


6. How Extensible is the New IOTS in Terms of the Use of Different 
Types of Databases and Different Operating System Environments? 


The IOTS was designed with interoperability in mind. The issue of platform and 
operating system dependence was discussed in the beginning of this chapter. In Chapter 
IV the IOTS was designed to use a single IOTS database since the requirements did not 
call for more than one database. 

Systems are moving targets. In the future, the QSI may need to connect to more 
than one database since the business environments keep changing and the initial 
requirements are likely to change over time. Currently, the CMO centrally manages the 
inventory levels across all the warehouses. One possible scenario is to decentralize this 
management process so that the warehouses completely performe it. In this scenario, 
each warehouse will have its own database, the LSMs will be granted much more 
authority, and they will be able to choose their suppliers. Meanwhile, the CMO of the QSI 
will maintain the right to monitor the progress in all of its warehouses and as well as the 
right to interfere if something goes wrong. Figure 44 shows how a single application may 
be able to access multiple databases even though these databases belong to different 
DBMS vendors. The driver manager intermediates the client application program and the 
DBMS drivers. When the application requests a connection with a database, the driver 


manager determines which DBMS driver 15 requested and loads it into memory. 
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Figure 44. An Application Program Accessing Multiple Databases 


The function of the DBMS driver is to receive requests from the application and 
format and deliver them to the appropnate DBMS. It also receives the responses from the 
DBMS and formats them for the application. The Open Database Connectivity (ODBC) 
standard is an interface that can connect to multiple kinds of databases that are ODBC 
compliant. With ODBC, the QSI can create a single application that connects to databases 
from different vendors. ODBC drivers must be installed on every client machine. This 
means that it will be a poor choice for Web-based database systems. In the IOTS 
prototype, however, we used the Oracle JDBC thin driver rather than tœ ODBC driver. 
The JDBC is a Java API that makes it easy to provide a “pure Java” large-scale solutions. 
The JDBC thin driver can be downloaded on the fly and, therefore, eliminates the need to 
install it on the client’s machine. This approach separates the middle tier from the 


database on the backend, which makes the system more scalable. 


В. CONCLUSIONS 


The focus of this research was to design and implement a component-based three- 
tiered Web-based system prototype that enables our enterpnse's applications to 
interoperate, scale and to exist on different platforms and different operating systems. 
Component-based distributed systems lower the cost of development and maintenance. 
Our prototype uses CORBA, an industry-backed, non-proprietary, standard-based 
distributed architecture and Java, a high-level object-oriented language that enables 
enterprises to deliver executable code over the Intemet. CORBA and Java allow the 
prototype to run on different operating systems and on multiple platforms. Moreover, the 
prototype makes it feasible to use different software components from different vendors. 
These components do not have to be implemented in the same programming language as 
long as they support the same IDL interface. Therefore, enterprises can mix and match 
software components according to their needs and will not be locked into a certain 
vendor. | 

The prototype has demonstrated how to overcome the stateless nature of the 
HTTP and build the Object Web by using CORBA and Java. The prototype’s client is 
packaged into a single HTML page that contains several components, thus clients can 
interact with server objects by clicking any of these components without switching a 
page's context to obtain each response. 

The source code for the prototype can be tailored to specific business 
requirements. Enterprises, with similar problems to those addressed here, may adopt the 


development methodology used in this research to solve their own specific problems. 
С. AREAS FOR FURTHER RESEARCH 


This research can be explored further in the following areas: 


t Scalability and load balancing. We have used a dispenser object to 
provide scalability and load balancing. In practice, a Transaction 
Processing (TP) monitor should be used to handle the interactions between 
client and server objects. In addition to a TP monitor, we recommend 
building a benchmark that tests the scalability of the IOTS prototype when 
large numbers of customers acess the CORBA server at the same time. 
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Security. The Visibroker SSL package can be purchased and used to 
provide secure connections between client and server objects. 


Server Manager(SM). The Object Web simplifies building an SM tool 
that monitors and controls all of the objects in the system. One way to 
build an SM is to register clients, servers, and SM objects with one or 
more coordinator objects. An SM GUI will use the coordinator to control 
and monitor the objects registered with it. For example, the SM will be 
able to monitor what each client is doing and can even terminate clients. 
The SM can also be designed to set the CORBA callback feature to on or 
off. If this feature is set, then the server objects will be able to update the 
clients with the most recent information. For example, An LSMs’ display 
can automatically be updated to reflect the most recent prices without any 
interference from the user. 


Benchmarking with RMI, DCOM, and other object-oriented 
languages. We have used CORBA as a backbone for our prototype, but 
different middleware tools, like RMI and DCOM, can be used and 
benchmarked to show a comparison among different implementations. 
Server objects can be implemented with C++ or other object-oriented 
languages instead of Java in order to test whether this implementation 
provides a significant performance increase over the approach we used in 
our prototype. 


Applications vs Applets. The prototype uses applets as a front end. This 
approach is suitable for Internet customers where clients download the 
most recent GUIs. If, however, we have a limited number of LSMs, the 
software distribution is not a problem, and the LSMs interface does not 
change frequently, we might consider providing the LSMs with 
applications not applets. In this approach we sacrifice the automatic 
upgrade feature of the system for the sake of not downloading the ORB 
classes every time a client makes a connection with the system. 
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ACS 
API 
BOA 
CGI 
CMO 
CORBA 
DCOM 
DDL 
DII 
DML 
E-R 
ESQL 
GIOP 
GSM 
ICMS 
IDL 
ПОР 
IOTS 
JDBC 
JDK 
JVM 
LSM 
MIS 
ODBC 
OMG 
ORB 
PERS 
QSI 
SGML 
SM 
SOM 
SQL 


APPENDIX A. ACRONYMS AND TERMS 


Accounting System 

Application Programming Interface 
Basic Object Adapter 

Common Gateway Interface 

Central Management Office 

Common Object Request Broker Architecture 
Distributed Component Object Model 
Data Definition Language 

Dynamic Invocation Interface 

Data Manipulation Language 

Entity Relationship model 

Embedded Structured Query Language 
General Inter-ORB Protocol 

Global Store Manager 

Inventory Control and Management System 
Interface Definition Language 

Internet Inter-ORB Protocol 

Inventory Ordering and Tracking System 
Java Database Connectivity 

Java Development Kit 

Java Virtual Machine 

Local Store Manager 

Management Information System 

Open Database Connectivity 

Object Management Group 

Object Request Broker 

Personnel System 

Quick Supply Incorporation 

Standard Generalized Markup Language 
Schema Manager 

Semantic Object Model 

Structured Query Language 

Unified Modeling Language 

Extended Markup Language 
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APPENDIX B. DEMARCO AND YOURDAN’S SYMBOLS FOR DFD’S 


This Appendix shows the DeMarco and Yourdon’s symbols conventions used in 


plotting both of the logical and physical DFDs throughout this research. 


E IM uu 
2 жесе on 
Е 2 
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APPENDIX C. LIST OF SOME OF IOTS QUERIES 


The following is a list of some of the major queries provided by the IOTS. 
Althoush users with different access levels may be allowed to perform the same query, 
they may not get the same result; the security access levels govern query results, and 


information is provided on a need-to-know basıs: 


e List the available balance of a given inventory. 

ө List the data record of a given inventory. 

ө List the final status on any given order. 

• List atrack of all the states on any given order along with the date on 


which each status took place. 
• List the history of any given inventory within a date range. 


ө List the orders that are Booked, Canceled, Confirmed, Deleted, Waiting, 
Dues/In, Dues/Out, or shipped for a given inventory in a given store. 


• List the orders placed on any given inventory along with their states. 
• List the status of all the ordered reports within a date range. 
• List the reports that are ready to be picked up. 
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APPENDIX D. LIST OF REPORTS 


The following is a list of some of the major reports provided by the system: 


No 


A report that shows the tracking status for a group of orders. This report 
shows the consecutive status taken on each order with the date of each 
status for a given store. 


A consumption report which shows the items issued to a given store 
within a date range. 


A report of Booked, Confirmed, Shipped, Canceled, Deleted, Due-in (D/T), 
and Due-out (D/O) orders for a given store. 


A report of the orders waiting for an action. 


A Statistical report of the number of Booked, Deleted, Confirmed, 
Shipped, Canceled, Deleted, DI, and DO orders grouped by the onginating 
warehouses. Another similar report must be grouped by the GSMs. 


A statistical report of the amount of money each GSM spent on 
purchasing. 


A report of dead stock inventory which has been bought but not sold for a 
predefined period of time. 


A report of the entire inventory available in a given store. This report will 
show the stock numbers, part numbers, items description, and the available 
balance of these items. 


A history report for a group of items that shows all the transactions 
performed on these items within a date range. 
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APPENDIX E. COMPARING JAVA/CORBA ORBS AND THEIR 
COMPETITION 


The following table shows Orfali and Harkey’s rating for the major six Object 
Web technologies. Four stars represent the highest (best) rating. A blank represents the 


worst rating; it means the function does not exist. 


Feature CORBA/ | DCOM HTTP | Servlets | Sockets 
IIOP me ae 


Abstraction level | level seek | Be |  жжжж | 


ED QU — — ——— 
OS platform support 
АП Java implementation [= |“ [sms ИИ БИ ИИ 
Typed parameter suppor — A BE жш 


E Ease of configuration - configuration 


Be Der E 
invocation 

mee а и 
MEN LL support 


| Dynamic invocation | amic invocation БЕСІН Ca 


Performance (remote pings) — 
3.5 ms 38 ms |33 827.9 |55.6ms si ms 
| ms 


Wire-level securit e ВНИИ БОННИ 
Wire-level transactions 


Persistence object а 

г 

| URL-based naming | based naming pers | EN Bar | 
Multilingual object =— a EL рш 
invocations 

Language-neutral wire kak k k жжжж жжжж жжжж 

EE A 


Cent И 
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APPENDIX F. ENTERPRISE LEVEL DATA SUBJECT DEFINITION 


Data Subject Name | Data Subject Definition 


Contains general information about all items, such as item name, 
CUSTOMER Anyone who contacts the QSI to place an order. Contact might be 
performed by using web-browsers, email, telephone, fax, regular 
mail, ın person, etc. 
Contains information about each invoice billed to a customer 


ORDERS An order is any request for an item or items offered for sale in the 
business of the QSI. The LSMs can also order reports from the 
CMO. 
Each single transaction has a unique code, description, and effect 


USERS This data subject contains the authorized users who have access to 
the IOTS. It contains LSMs, GSMs, customers, and MIS users. 
This data subject contains the users’ Security Access Levels. 
Although the DBMS will take care of security, this data subject is 
required to provide security on the application level. 


WAREHOUSE Keeps a list of all the necessary information about all QST’s 







component identification, part number, unit of sale, item price, 


CAG, 















on inventory levels. 





warehouses. For each warehouse, this data subject will include the 


name, address, phone(s), fax(s), email, etc... 
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APPENDIX G. ENTERPRISE LEVEL ATTRIBUTE DEFINITION 


This Appendix contains a list of candidate attributes that will be used in the IOTS 


database: 


Definition 

Available quantit 

Component identification number 

Credit card expiration date 

Credit card number 

Credit card type 

Customer’s first name 

Customer’s identification number 

Customer’s last name 

Email address 

Fax number 

Invoice date 

Invoice identification 

Invoice total amount due 

Component name 

Date and time of the order placement 

Order identification number 

Component part number 

Purchase price of an item 

Quantity ordered 

A note that explains why an order is deleted of canceled 
When the reorder level quantity is reached, the warehouse 
places a new order to make this inventory available for 
future requests. 
ReorderQty The quantity ordered when the ReorderLevel quantity is 
reached 

ResAddrCit City of residence address 


State of residence address 
Street of residence address 
SalePrice 
ShipAddrState State of shipping address 
ShipAddrStreet Street of shipping address 
ShipddrZip Zıp code of residence address 


Attribute Definition 


Attribute 
Balance 

ItemID 
CreditCardExpDate 
CreditCardNumber 
CreditCardT ype 
CustomerFirstName 
CustomerID 
CustomerLastName 
EmailAddr 

Fax Number 
InvoiceDate 
InvoiceID 
InvoiceTotal 
ItemDescniption 
OrderDateAndTime 
OrderID 
PartNumber 
PurchasePrice 
Quantit 

Remarks 
ReorderLevel 
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| Status 

| StatusDateAndTime 
Tax 
Taxableltem 


TelephoneNumber 
TotalDue 
TransactionCode 
TransactionDesc 
UnitOfPurchase 
UnitOfSale 
UserAccessLevel 
UserID 
UserName 
UserPassword 
WareAddrCit 
WareAddrState 
W areAddrStreet 
WareAddrZip 

W arehouselD 
WarehouseName 


Order’s status 


Date and Time on which a status took place 
Tax amount due 

Boolean flag contains true if the item is taxable; 
otherwise it contains false 

Telephone number 

Total amount due for an order 

The code of a transaction 

The description of a transaction 

Unit of purchase (ex EA, PK, DZ, etc) 

Unit of sale 

User access level (LO, L1, L2, L3, and LA) 
User log on identification 

The complete name of the user 

The password of the user (Stored encrypted) 
City of warehouse address 

State of warehouse address 

Street of warehouse address 

Zip code of warehouse address 

Warehouse identification code 

Name of the Warehouse 


APPENDIX H. ENTERPRISE LEVEL DATA SUBJECTS’ ATTRIBUTES 


This Appendix lısts the attrıbutes of each data subject: 


Data Subject Entity Type | Attributes 
Name 


ITEM Independent | ItemID, ItemDescription, PartNumber, 





PurchasePrice, UnitOfPurchase, SalePrice, 
UnitOfSale, Taxableltem 
CUSTOMER Independent | CustomerID, CustomerName, ResAddrStreet, 


ResedenceAddress, Shipping Address, 


TelephoneNumber, FaxNumber, Email Address, 
CreditCardNumber, CreditCardExpDate, 
CreditCardT ype 

INVENTORY Dependent InventoryID, Balance, ReorderLevel, ReorderQty 


INVOICE = InvoicelID, InvoiceDate, ORDERS, InvoiceTotal 


E Dependent | OrderID, OrderDateAndTime, CustomerID, 
LineItem (ItemID, Quantity, UnitPrice, 
ExtendedPrice), Tax, TotalDue, StatusTrackInfo 
(StatusDateAndTime, Status, Remarks) 


TRANSACTION Independent | TransactionCode, TransactionDesc 
USERS | Independent | UserID, UserName, UserAccessLevel 


E — Independent | WarehouseID, InventoryID, WarehouseName, 
WarehouseAddress, FaxNumber, 
TelephoneNumber 
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APPENDIX J. SEMANTIC DATA MODEL FOR THE IOTS 


This appendix lists the IOTS semantic data model developed using “SALSA for 


disk top” modeling tool 


El SALSA for the Desktop - [DATAMO~1_APM] | 
[5] File Edit View Design Tools Options Window Help 


Dee) Es} Jas м 


18 


ІН) Ғе Edit View Design Jools Options Window Help 


*CustomerlD 1.1 

* CustomerN ame 1.1 
Fesiderceäddress p.1 
Shipping&ddress р.р = 
O Street 4.4 

City 1.1 

C) State 1.1 

O Zip 1-1 
TelephoneNumber 1.1 
Fa=Number 9.1 
Emailáddress 0.1 
CreditCardinta 1.1 > 
CreditCardNumber ı.ı 
O CreditCardExpDate ı.ı 
O CreditCardT ype 1.1 


ORDERS lo.n 


E ORDERS 


| O tOrderD 1-1 
OrderDateAndT ime 1.1 
E м 
| [CUSTOMER]. 


i 25 Опећегт in > 


E HITEM | 1.1 


G Quantity 1-1 


ExtendedPrice 1.4 


Tax 1.1 
TotalDue 1.1 


StatusTrackinto 1.N 
O tStatusDateA&ndT ime 1.1 


E |USERS |1.1 


Ol Status 1.1 
Remarks о.1 


>| ори РЕ 
E] USERS 
O *tUserlD 1.1 
O UserName 1.1 
C? UserSccessLevel 1.1 


Ша 


Е TRANSACTION 4 
O Рутту fade 1-1 
O TransactionDesc y.1 


| [ORDERS Jo. 


= INVOICE 
ID ЕЮ 1-1 
10 InvoiceDate 1.1 


eS InvoiceLineltem |. = 


E] FORDERS | 1.1 


10 InvoiceTotal 1.1 


DER х Ы 
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[WVENTORY]o. 
*ltemDescniption 1.1 
*PartNumber 1.1 
PurchasePrice 9.1 
UnitOfPurchase 9.1 
SalePrice 12] 
UrutOfS ale 1.1 

T axableltem 1.1 


. 


a INVENTORY 


25 Жіпуетішііб er 


[3] |ТЕМ ||.) 
E] [wAREHOUSE | 4.1 


10 Balance 1.1 


б Веогдег еме! 1.1 


l8 Реогде у 1.1 





=] WAREHOUSE 


IQ #WarehouselD 4.1 


| [2] INVENTORY {1.Nn 


O "WarehouseName 1.1 
о8 Матећоиседддге55 EE E. 
AR | 
City 4.4 
O State 1.1 
O Zip 1.1 


| B. FaxNumber 1.1 


O TelephoneNumber 1.1 
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APPENDIX L. DATABASE DEFINITION 


This Appendix lists the IOTS database definition wnitten ın the SQL DDL. It 


defines the tables, indexes, attributes, primary keys, foreign keys, and constraints. 
с 


7s 


REM // struct.txt contains IOTS database structure definition 
REM // last modified 02/17/2000 


E 


REM Table: ITEM 


DROP TABLEITEM CASCADE CONSTRAINTS; 


CREATE TABLE ITEM ( 
ItemID VARCHAR2(13) PRIMARY KEY, 
ItemDescreption VARCHAR2(30) NOT NULL, 
PartNumber VARCHAR2(25) NOT NULL, 
PurchasePrice NUMBER($,2), 
UnitOfPurchase CHAR(2), 
SalePrice NUMBER (8,2) NOT NULL, 
UnitOfSale CHAR(2) NOT: NULL, 
Taxableltem CHAR(1) NOT NULL 


ЈЕ 


REM Table: CUSTOMER 


DROP TABLE CUSTOMER CASCADE CONSTRAINTS; 


CREATE TABLE CUSTOMER ( 
CustomerlD VARCHAR2(13) PRIMARY KEY, 
CustomerName VARCHAR2(30) NOT NULL, 
ResAddrStreet VARCHAR2(50) NOT NULL, 
ResAddrCity VARCHAR2(25), 
ResAddrState CHARO), 
ResAddrZip CHAR(10), 
ShipAddrStreet VARCHAR2(50) NOT NULL, 
ShipAddrCity VARCHAR2(25) NOT NULL, 
ShipAddrState CHAR(2) NOT NULL, 
ShipAddrZip СНАК(10) NOT NULL, 
TelephoneNumber СНАК(12) NOT NULL, 
FaxNumber VARCHAR2(12), 
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EmailAddress VARCHAR2(35), 
CreditCardNumber CHAR(I6) NOT NULL, 
CreditCardExpDate DATE NOT NULL, 
CreditCardType VARCHAR2(20) NOT NULL ); 


REM Table: WAREHOUSE 


DROP TABLEWAREHOUSE CASCADE CONSTRAINTS; 
CREATE TABLE WAREHOUSE ( 
WarehouseID VARCHAR2(5) PRIMARY KEY, 
WarehouseName VARCHAR2(35) NOT NULL, 
W areA ddrStreet VARCHAR2(50) NOT NULL, 


WareAddrCity VARCHAR2(25) NOT NULL, 
WareAddrState СНАК(2), 

WareAddrZip СНАК(10) NOT NULL, 
FaxNumber | СНАК(12) NOT NULL, 
TelephoneNumber CHAR(I2) NOT NULL 


р 
REM Table: INVENTORY 


DROP TABLE INVENTORY CASCADE CONSTRAINTS; 
CREATE TABLE INVENTORY ( 


ItemID. FK VARCHAR2(13) REFERENCES ITEM, 
WarehouseID ЕК VARCHAR2() REFERENCES WAREHOUSE, 
Balance NUMBER (10,2) NOT NULL, 

ReorderLevel NUMBER (10,2) NOT NULL, 

ReorderQty NUMBER(10,2) NOT NULL, 


PRIMARY KEY (ItemID_FK, WarehouseID_FK) 
|. 


JF. Жжжж жж жож ж жок жок ж ЖЖЖ ЖЖЖ ЖоК ЖЖ Ж ЖОК ЖКК ЖЖЖ ЖЖЖЖ ЖК ЖЖЖ ЖКК ACK HC Ж/ 
REM TABLE: INVOICE 


DROP TABLE INVOICE CASCADE CONSTRAINTS; 


CREATE TABLE INVOICE ( 
InvoiceID VARCHAR2(13) PRIMARY KEY, 
InvoiceDate DATE NOT NULL, 
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InvoiceTotal NUMBER(10,2) NOT NULL 
); 


REM TABLE: INVOICE_DETAILS 


DROP TABLE INVOICE_DETAILS CASCADE CONSTRAINTS; 
CREATE TABLE INVOICE_DETAILS ( 
InvoiceID_FK VARCHAR2(13) REFERENCES INVOICE, 
OrderID_FK VARCHAR2(13) REFERENCES ORDERS, 
PRIMARY KEY (InvoiceID FK, OrderID FK) 


| 


REM TABLE: TRANSACTION 


DROP TABLE TRANSACTION CASCADE CONSTRAINTS; 
CREATE TABLE TRANSACTION ( 
TransactionCode CHAR(3) PRIMARY KEY, 
TransactionDesc VARCHAR2(50) NOT NULL 


); 
REM TABLE: USERS 


DROP TABLE USERS CASCADE CONSTRAINTS; 
CREATE TABLE USERS ( 


UserlD VARCHAR2(13) PRIMARY KEY, 
UserName VARCHAR2(30) NOT NULL, 
UserAccessLevel CHAR(2) NOT NULL 


D: 
REM TABLE: ORDERS 


DROP TABLE ORDERS CASCADE CONSTRAINTS; 
CREATE TABLE ORDERS ( 


OrderID VARCHAR2(13) PRIMARY KEY, 
CustomerID FK VARCHAR2(13) REFERENCES CUSTOMER, 
OrderDateAndTime DATE NOT NULL, 


TransactionCode_FK CHAR(3) REFERENCES TRANSACTION, 


14] 


Тах NUMBER(10,2) NOTANUEE: 
Total Due NUMBER(10,2) NOT NULL, 
InvoiceID_FK VARCHAR2(13) REFERENCES INVOICE 


js 
REM TABLE: ORDER. DETAILS 


DROP TABLE ORDER. DETAILS CASCADE CONSTRAINTS; 
CREATE TABLE ORDER . DETAILS ( 
OrderID FK VARCHAR2(13) REFERENCES ORDERS, 
кето ЕК VARCHAR2(13) REFERENCES ITEM, 
Quantity NUMBER (10,2) NOT NULL, 
UnitPrice NUMBER (08,2) NOT NULL, 
ExtendedPrice NUMBER (10,2) NOT NULL, 
PRIMARY KEY(OrderID FK, ItemID FK) 


); 
REM TABLE: ORDER_STATUS 


DROP TABLE ORDER_STATUS CASCADE CONSTRAINTS; 
CREATE TABLE ORDER_STATUS ( 


OrderID_FK VARCHAR2(13) REFERENCES ORDERS, 
StatusDateAndTime DATE NOT NULL, 

UserID_FK VARCHAR2(13) REFERENCES USERS, 
Status VARCHAR2(20) NOT NULL, 

Remarks VARCHAR2(50), 


PRIMARY KEY(OrderID FK, StatusDateAndTime, UserID. FK) 
); 


APPENDIX M. IDL SPECIFICATIONS FOR THE IOTS PROTOTYPE 


This Appendix contains the IDL file used to define the ınterface among the IOTS 
CORBA objects: 


module Iots 


{ 

struct customerStruct 
{ 
string customerID; 
string name; 
string bStreet; 
string DCity. 
string bState; 
string bZipCode; 
string sStreet; 
stering SCity; 
string sState; 
string sZipCode; 
string telephone; 
String phax; 
string email; 
string creditCardNo; 
string expDate; 
string creditCardType; 
p 


typedef customerStruct cusStruct; 


struct warehouseStruct 

( 

string sWarehouseID; 
string sWarehouseName; 
string sWareAddrStreet; 
string sWareAddrCity; 
string sWareAddrState; 
string sWareAddrZip; 
string sFaxNumber; 
string sTelephoneNumber; 
DE 


typedef warehouseStruct wareStruct; 


struct balanceStruct 
( 
string sItemID; 
string sItemDescreption; 
string sPartNumber ; 
string sTaxableltem; 
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float sSalePrice; 
Struma sUnitOfsale; 


string sWarehouselD; 
string sWarehouseName; 


float sBalance; 
float sReorderLevel; 
float sReorderOty; 
a 
typedef balanceStruct рај висе; 


struct IDsStruct { 
string sWarelD; 
ры 
typedef sequence<IDsStruct> warelDs; 


struct ItemIDsStruct { 
Ser2ing: sksemID; 
ре 
typedef sequence<ItemIDsStruct> itemIDs; 


struct ItemIiDsStruct2 ( 
string sItemID; 
string sItemDescreption; 
float  sSalePrice; 
E 
typedef sequence<ItemIDsStruct2> itemIDs2; 


struct TransactionStruct { 
string sTransactionCode; 
string sTransactionDesc; 
Inm 


typedef sequence<TransactionStruct> transIDs; 


struct CustomerIDsStruct ( 
string sCustomerID; 
string sCustomerName; 
jos 
typedef sequence<CustomerlDsStruct> cuslDs; 


struct OrderStruct { 
string itemID; 
string itemDescreption; 
long quantity; 
float salePrice; 
float extendedPrice; 
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float tax: 
float total; 
DE 
typedef sequence<OrderStruct> ordStruct; 


struct OrderResultStruct { 
string sOrderID; 
string sMessage; 
Hs 
typedef OrderResultStruct ordResult; 


struct StatStruct ( 
string SUSerID; 
string sTransactionCode; 
string sCustomerID; 
string sOrderDateAndTime; 
float  sTaxAll; 
float sTotalDue; 

ie: 

pwupecderStaecotmruct stStruct; 


struct OrderMainInfoStruct { 
string sOrderID; 
string sCustomerID; 
string sTax; 
string sTotalDue; 
string sOrderDateAndTime; 
string sInvoicelD; 
string sStatus; 

ju 


typedef sequence«OrderMainInfoStruct» mainInfo; 


struct StatusStruct { 
string sStatusDate; 
string sStatus; 
string sRemarks; 
pu 
typedef sequence<StatusStruct> statseg; 


interface IotsMed 


{ 


void addCustomer (in customerStruct cusStruct); 
cusStruct getCustomer (in string cusID); 
void modCustomer (in customerStruct cusStruct); 


void addWarehouse (in warehouseStruct wareStruct); 
wareStruct getWarehouse (in string warelD); 
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void modWarehouse (in warehouseStruct wareStruct); 


balStruct getBalance (in string cusID, in string 
warelD); 


warelDs getWarelDs (); 
itemIDs getlItemIDs(); 
itemIDs2  getItemIDs2(); 


boolean connect (in string user, in string password); 


transIDs  getTransIDs(); 
CUIUS getCusIDs(); 


string getDate(); 


ordResult placeOrder(in ordStruct inOrder, in stStruct 
stat); 


mainlInfo getOrderMainInfo( 
in String orderi) а= сета рле жп 
string hDate ); 
statseq getStatus (in string orderID) ; 


} , 


interface IotsDispenser 


{ 


IotsMed reserveObject (); 
уола releaseObject (in IotsMed iotsmed) ; 


06 
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APPENDIX N. INDEX.HTML CODE 


This Appendix contains the HTML code for the Index.htm. This code was built 


using Microsoft Frontpage 98 and was used to embed the applet “lotsApplet .class”. 


<html> 

<head> 

<meta name="GENERATOR” content="Microsoft FrontPage 3.0"> 

<meta name="Microsoft Theme" content="none, default"> 

<title>Inventory Ordering and Tracking System (IOTS)</title> 

<meta name="Microsoft Border" content="none, default"> 

</head> 

<body becolor="#FFFFFF"> 

<hl align="center"><img src="flower.jpg" width="38" height="55" 

alt="flower.wmf (8182 bytes)” alien="left"><font color="*FF0000"> 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; 

Quick Supply Inc.</font> 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; 

<img src="AG00001_.gif" width="39" height="47" alt="AG00001_.gif (4995 bytes)"> 
</hl> 

<hl align="center"><font color="#FF0000" size="4">LSMs Cotrol Page </font><img 
src="WB01385_.g1f" width="500" height="4" alt="WB01385_.gif (6261 bytes)"></h1> 
<p align="center"> | 

<object classid="clsid:3AD9C840-044E-11D1-B3E9-00805F499D93" WIDTH="301" 
HEIGHT="90" 

codebase="http://java.sun.com/products/plugin/1.2/jinstall-12- 


wın32.cab#Version=1,2,0,0" 
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align="left"> 
<param name="CODE" value="lotsApplet.class”> 
<param name="type" value="application/x-java-applet;version=1.2"> 
<param name="org.omg.CORBA.ORBClass" value="com.visigenic.vbroker.orb.ORB"> 
<param name="ORBgatekeeperlOR" value="http://computerb: 15000/gatekeeper.ior"> 
<param name="ORBalwaysProxy" value="true"> 
<param name="ORBservices” value="CosNaming"> 
<param name="SVCnameroot” value="lotsNames”><> <embed type="application/x- 
java-applet;version=1.2" java_CODE="TotsApplet.class" 
WIDTH="600" HEIGHT="350" 
org.omg.CORBA.ORBClass="com.visigenic.vbroker.orb.ORB" 
ORBgatekeeperlOR="http://computerb:15000/gatekeeper.¡or” ORBalwaysProxy="true" 
ORBservices="CosNaming" SVCnameroot="IotsNames" 
pluginspage="http://java.sun.com/products/plugin/1.2/plugin- 
install.html"><noembed></COMMENT> 
</noembed> 
</object> 
</p> 
<!-- 


<APPLET CODE = lotsApplet.class WIDTH = 600 HEIGHT = 350 > 
<PARAM NAME = org.omg.CORBA.ORBClass VALUE 
=com.visigenic.vbroker.orb.ORB> 

<PARAM NAME = ORBgatekeeperIOR VALUE 

=http://computerb: 15000/gatekeeper.ior> 

<PARAM NAME = ORBalwaysProxy VALUE =true> 

<PARAM NAME = ORBservices VALUE =CosNaming> 

<PARAM NAME = SVCnameroot VALUE =lotsNames> 
</APPLET> --> 


<!--"END_CONVERTED_APPLET"--> 
</body> 
</html> 
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APPENDIX O. SOFTWARE COMPONENTS USED IN THE IOTS 


The following table lists the various software components and development tools 


used to design and implement the IOTS prototype: 


Development To draw UML diagrams for the IOTS prototype. 


and To pass SQL commands to the IOTS database on the 

Deployment back end for testing purposes 

Tools 
To develop the IOTS Java classes 


To develop the main page of the IOTS prototype that 
Frontpage 98 hosts the IOTS’s applet. 
Visibroker 3.4 


JVM Plug-ins To enable Web browsers to overnde their old 

1.22 backed-in JVMs. These plug-ins will make it 

possible for Web browsers to execute the prototype 
that was developed with JDK 1.2.2 
Microsoft Internet | To provide HTTP service 
Information 
Server (IIS) 


To act as a proxy server that overcomes some of the 
Gatekeeper 3.3 applet's limitations 

To connect the middle tier with the IOTS database 
thin driver on the back end 


Netscape and Used for testing purposes 
Microsoft Internet 
explorer 


IOTS lotsApplet, lotsLSMsBean, lotsServer, To provide the IOTS 
Prototype IotsDispenserImpl (by Orfali and Harkey), prototype with the 
IotsMedImpl, IotsDBClass, SecurityBean, required 
WarehouselnfoBean, CustomerBean, functionalities 
PlaceOrderBean, TrackOrderBean, BalanceBean, 
lots.Idl, index.htm 
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APPENDIX P. SOURCE CODE OF THE IOTS PROTOTYPE 


This Appendix lists the source code of the IOTS prototype. It lists the code for the 
following classes: 
° lotsApplet 
° JotsServer 
• IotsLSMsBean 
• IotsDispenserImpl 
• IotsMedImpl 
ә IotsDBClass 


• SecurityBean 

• WarehouselnfoBean 
~ CustomerBean 

• PlaceOrderBean 


ы ТгаскОгдегВеап 


è BalanceBean 


А. ЈОТЗАРРГЕТ 


/NotsApplet.java 
import java.awt.*; 
import javax.swing.*; 
import java.applet.*; 
import lotsLSMsBean; 
public class lotsA pplet extends JA pplet 
{ 
private IotsLSMsBean lotsLSMsBeanl; 
public void init() 
{ 
getContentPane().setLayout(new BorderLayout(0,0)); 
setSize(600,350); 
lotsLSMsBeanl = new IotsLSMsBean(this); 
IotsLSMsBeanl .setBackground(java.awt.Color.orange); 
getContentPane().add("Center" ,lotsLSMsBean 1); 
Vnit 
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public void destroy() 


IotsLSMsBean 1 .releaseDBObject(); 


| 
Y/Iots Applet 


B. IOTSSERVER 


1 1015 Зегует. јама 
import org.omg.CosNamin g.*; 
public class lotsServer 
{ static public void main(String[] args) 
| 
int numberInstances; 
(гу 
{ 
if (args.length == 0) 
numberlnstances = 4; 
else 
numberInstances - Integer.parseInt(args[0]); 
// Initialize the ORB 
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB. init(args, null); 
// Create the lotsDispenser object 
lotsDispenserImpl dispenser = 
new IotsDispenserlmpl(args, "My Dispenser", numberlInstances); 
// Export the newly create object 
orb.connect(dispenser); 
// Get a reference to the Naming service 
org.omg.CORBA.Object nameServiceObj = 
orb.resolve initial references ("NameService"); 
if (nameServiceObj == null) 
| 
System.out.printIn("nameServiceObj = null"); 
return; 
} 
org.omg.CosNaming.NamingContext nameService = 
org.omg.CosNaming.NamingContextHelper.narrow(nameServiceObj); 
if (nameService == null) 
| 
System.out.printIn("nameService = null"); 
return; 


} 
// bind the lotsMed object in the Naming service 
NameComponent[] IotsName = {new NameComponent("IotsMed", "")}; 
nameService.rebind(IotsName, dispenser); 
// wait forever for current thread to die 
Thread.currentThread().join(); 

} catch(Exception e) 

( System.err.println(e); 

} 

} 


V//TIotsServer 


e IOTSLSMSBEAN 


Лов 5 МзВеап. јама 

Import Java.awt.”; 

import java.util.*; 

import java.awt.event.*; 

import javax.swing.*; 

import java.applet.Applet; 

import org.omg.CosNaming.*; 

public class lotsLSMsBean extends JPanel { 


private JTabbedPane jtp; 
private org.omg.CosNaming.NamingContext nameService; 
private Iots.IotsDispenser myDispenser; 
private lots.lotsMed mylotsMed; 
private CustomerBean customerBean; 
private WarehouselnfoBean warehouselnfoBean; 
private BalanceBean balanceBean; 
private SecurityBean securityBean; 
private PlaceOrderBean placeOrderBean; 
private TrackOrderBean trackOrderBean; 
public lotsLSMsBean(JApplet japp) ( 
setS1ze(600,350); 
initializeORB(japp); 


setLayout(new BorderLayout()); 

Jtp = new JTabbedPane(); 

JPanel placeOrdersPanel = new JPanel(); 
placeOrdersPanel.add( 
placeOrderBean= new PlaceOrderBean(mylotsMed)); 

JPanel trackOrdersPanel = пем ЈРапе1); 
trackOrdersPanel.add( 
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trackOrderBean = new TrackOrderBean(mylotsMed)); 
JPanel avaılableBalancePanel = new JPanel(); 
availableBalancePanel.add( 
balanceBean= new BalanceBean(mylotsMed)); 
JPanel warehouselInfoPanel = new JPanel(); 
warehouselnfoPanel.add( 
warehouselnfoBean = new WarehouselnfoBean(mylotsMed)); 
//History, order and track reports are not implemented 
JPanel historyPanel = new JPanel(); 
JPanel orderReportPanel = new JPanel(); 
JPanel trackReportsPanel = new JPanel(); 
JPanel customerPanel = new JPanel(); 
customerPanel.add( 
customerBean = new CustomerBean(mylotsMed)); 
JPanel secuntyPanel = new JPanel(); 
securityPanel.add( 
securityBean = new SecurityBean(mylotsMed,myDispenser)); 
jtp.addTab("Log On”, securityPanel); 
jtp.addTab(" Place Orders", placeOrdersPanel); 
jtp.addTab(" Track Orders", trackOrdersPanel); 
jtp-addTab(" Available Balance", availableBalancePanel); 
jtp.addTab(" Warehouse Information", warehouseInfoPanel); 
jtp.addTab( "Transaction History", historyPanel); 
jtp.addTab( Order Reports", orderReportPanel); 
jtp.addTab(" Track Reports", trackReportsPanel); 
jtp.addTab(" Customer Service", customerPanel); 
// set background colors 
for (int 1=0; 1 < 9; 1++) 
| 
jtp.setBackgroundAt(1,java.awt.Color.green); 
| 
add("Center”,jtp); 
setVisible(true); 
} 
public void initializeORB(JApplet app) 
| 
try 
{ // Initialize the ORB 
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(app, null); 
// Get a reference to the Naming service 
org.omg.CORBA.Object nameServiceObj = 
orb.resolve initial. references ("NameService"); 
if (nameServiceObj == null) 
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| 


System.out.printIn("nameServiceObj = null"); 
retum; 
} 
Namcoervice — 
org.omg.CosNaming.NamingContextHelper.narrow (nameServiceObj); 
if (nameService == null) 
{ 
System.out.printin(’nameService = null”); 
return; 
} 
// resolve the db object reference 
NameComponent[] lotsName = ( 
new NameComponent("lotsMed", "") }; 
myDispenser = Iots.lotsDispenserHelper.narrow 
(nameService.resolve(lotsName)); 
if (myDispenser == null) 
{ 
System.out.printIn("Failed to resolve IotsMed"); 
retum; 
} 
mylotsMed = myDispenser.reserveObject(); 
} catch(Exception e) 
{ System.out.printIn("Exception” + e); 


Y/intializeORB 

public void releaseDBObject() 

{ try{ 
myDispenser.releaseObject(mylotsMed); 


| 


catch (Exception ex) 


| 


System.err.println(ex); 


} 
V/releaseDBObject 


V/IotsLSMsBean 


D. IOTSDISPENSERIMPL 


// lotsDispenserImpl.java 
public class IotsDispenserImpl 
extends lots._lotsDispenser{mp]Base 


| 
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private ınt maxObjects = 10; 
private int numObjects = 0; 
private JotsStatus[] JotsMed = 
new JotsStatus[max Objects]; 
public IotsDispenserlmpl() 
| 
super(); 
| 
public IotsDispenserImpl(java.lang.String[] args, 
java.lang.String name, int num) 
| 
super(name); 
цу 
| 
// get reference to orb 
org.omg.CORBA.ORB orb = 
org.omg.CORBA.ORB. init(args, null); 
// prestart n IotsMed Objects 
numObjects = num; 
for (int 120; 1 < numObjects; 1++) 
| 
IotsMed[i] = new lotsStatus(); 
IotsMedl[i].ref = new lotsMedImpl("IotsMed" + (1+1)); 
orb.connect(IotsMed[i ].ref); 
| 
) catch(Exception e) 
( System.err.println(e); 
| 
| 
public Iots.IotsMed reserveObject() 
{ 
for (int 1=0; 1 < numObjects; 1++) 
{ 
if ('IotsMed[i].inUse) 
( IotsMed[1i].inUse z true; 
System.out.printin("ClubMed” + (1+1) + 
" reserved."); 
return IotsMed[i].ref; 
| 
| 
return null; 
| 
public void releaseObject(Iots.IotsMed IotsMedObject) 
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| 


for (int 120; 1 < numObjects; i++) 


if (IotsMed[i].ref 22 IotsMedObject) 
| IotsMed[1].1nUse - false; 
System.out.println("IotsMed" + (1+1) + " гејеазед."); 
retum; 


} 
| 


System.out.printin("Sorry: Reserved Object not found"); 
return; 
} 
} 
class IotsStatus 
{ 
IotsMedImpl ref; 
boolean inUse; 
IotsStatus() 
Сте = null; 
inUse = false; 
} 
} 


E. IOTSMEDIMPL 


/! IotsMedlImpl.java 
import java.util.*; 
public class IotsMedImpl extends Iots. IotsMedImplBase 
{ 
private IotsDBClass mylotsDB; 
private String instanceName; 
static int MaxWarehouses=100; 
public IotsMedImpl(java.lang.String name) { 
super(name); 
uy 
{ 
mylotsDB = new IotsDBClass(); 
mylotsDB.connect(" system", "manager"); 
System.out.printIn("IotsMedDB Object " - name + " Created"); 
instanceName - name; 
! catch (Exception e) 
| System.out.println(" System Exception "); 


| 
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} 
public IotsMedImpl() 
{ 
super(); 
} 
public void addCustomer(lots.customerStruct cusStruct) 
{ 
try 
| 
mylotsDB.addCustomer(cusStruct); 
} catch (Exception e) 
| 
System.err.println("error in addCustomer() IotsMedImpl"); 
} 
V/addCustomer 
public void mod Customer(Iots.customerStruct cusStruct) 
{ 
try 
( 
mylotsDB.modCustomer(cusStruct); 
} catch (Exception e) 
{ 
System.err.println("error 1n modCustomerf) IotsMedImpl"); 
} 
Y/modCustomer 
public Iots.customerStruct getCustomer(String cusID) 
{ 
Iots.customerStruct cusStruct =null; 
try 
{ 
cusStruct = mylotsDB.getCustomer(cusID); 
} catch (Exception e) 
| 
System.err.println("error in getCustomer() IotsMedImpl"); 
} 
retum (cusStruct); 
}// getCustomer 


public void add Warehouse(lots.warehouseStruct wareStruct) 
| 

try 

| 


mylotsDB.addWarehouse(wareStruct); 
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} catch (Exception e) 
{ 
S ystem.err.println("error in addWarehouse() IotsMedImpl"); 
j 
//addWarehouse 
public void modWarehouse(lots.warehouseStruct wareStruct) 
{ 
пу 
( 
mylotsDB.modWarehouse(wareStruct); 
} catch (Exception e) 
{ 
System.err.println("error in modWarehouse() IotsMedImpl"); 
j 
//modCustomer 
public Iots.warehouseStruct getWarehouse(String warelID) 
{ 
Iots.warehouseStruct wareStruct =null; 
(гу 
( 
wareStruct = mylotsDB.getWarehouse(warelD); 
} catch (Exception e) 
{ 
System.err.println("error in getWarehouse() IotsMedImpl"); 
} 
return (wareStruct); 
}// getWarehouse 


public Iots.balanceStruct getBalance(String itemID, String wareID) 


Iots.balanceStruct balStruct =null; 

try 

{ 

balStruct = mylotsDB.getBalance(itemID, wareID); 

} catch (Exception e) 

{ 

System.err.println("error in getBalance() IotsMedImpl"); 


} 
retum (balStruct); 
}// getBalance 


public Iots.IDsStruct[] getWarelDs() 
{ 
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try 


lots.IDsStruct[] warelDs; 

Vector tempV = mylotsDB.getWarelDs(); 

warelDs = new lots.IDsStruct[tempV .size()); 
tempV.copyInto(warelDs); 

retum (warelDs); 

} catch (Exception e) 

( 

S ystem.err.println("error in getWareIDS() IotsMedImpl"); 
retum (null); 


} 
V/getWareIDs 


public Iots.ItemIDsStruct[] getItemIDs() 
( 
try 
{ 
Iots.ItemIDsStruct[] itemIDs; 
Vector tempV = mylotsDB.getltemIDs(); 
itemIDs = пем Iots.ItemIDsStruct[tempV .size()]; 
temp V.copylInto(itemIDs); 
return (itemIDs); 
) catch (Exception e) 
( 
System.err.prntin("error in getitemIDs() IotsMedImpl"); 
return (null); 


} 
V/getitemIDs 


public Iots.ItemIDsStruct2[] getItemIDs2() 
{ 
try 
| 
Iots.ItemIDsStruct2[] itemIDs2; 
Vector tempV = mylotsDB.getltemIDs2(); 
itemIDs2 = new Iots.ItemIDsStruct2[tempV.size()]; 
tempV .copyInto(itemIDs2); 
return (itemIDs2); 
) catch (Exception e) 
{ 
System.err.printin("error in getItemIDs() IotsMedlImpl"); 
return (null); 
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} 


V/getItemIDs2 


public Iots.TransactionStruct[] getTransIDs() 


{ 
try 
{ 
Iots.TransactionStruct[] transIDs; 
Vector tempV = mylotsDB.getTransIDs(); 
transIDs = new lots.TransactionStruct[tempV .sıze()]; 
temp V.copyInto(transIDs): 
return (transIDs); 
} catch (Exception e) 
{ 
System.err.printIn("error in getTransIDs() IotsMedImpl"); 
return (null); 


j 
V/getTransIDs 


public Iots. CustomerIDsStruct[] getCusIDs() 
( 
try 
{ 
lots. CustomerlDsStruct[ ] cusIDs; 
Vector tempV = mylotsDB.getCusIDs(); 
cusIDs = new lots.CustomerlDsStruct[tempV .size()]; 
tempV.copyInto(cusIDs); 
retum (cusIDs); 
) catch (Exception e) 
{ 
System.err.printin("error in getCusIDs() IotsMedImpl"); 
return (null); 


} 
V/getCusIDs 


public boolean connect( 
java.lang.String user, 
java.lang.String password) 
{ 
try 
{ 
mylotsDB.connect(user, password); 
return (true); 
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} catch (Exception e) 

= (false); 
ae 
public Iots.OrderResultStruct placeOrder( = 
lots.OrderStruct[] inOrder, Iots.StatStruct stat ) 


{ 
Iots.OrderResultStruct ordRes=null; 
цу 
{ 
ordRes = mylotsDB.placeOrder(inOrder, stat); 
return(ordRes); 
} catch (Exception e) 
{ | 
System.err.println("error in placeOrder() IotsMedImpl"); 
System.out.printIn("EID :"+ordRes.sOrderlD); 
System.out.printin("Emsg:"+ordRes.sMessage); 
return (new Iots.OrderResultStruct("not av","Un Successfull/MedImp")); 
} 
V// placeOrder 
public String getDate() { 
Date dt = new Date(); 
return(dt.toLocaleStnng()); 
}//getDate 


public Iots.OrderMainInfoStruct[] getOrderMainInfo( 
String orderID, 


String lDate, 
String hDate) 
| 
(гу 
| 
Iots.OrderMainlnfoStruct[] orders; 
Vector tempV z mylotsDB.getOrderMainInfo(orderID,lDate,hDate); 
orders 7 new Iots.OrderMainInfoStruct[tempV .size()]; 
tempV .copyInto(orders); 
return (orders); 
) catch (Exception e) 


| 


S ystem.err.println("error in getMainInfoStruct() IotsMedImpl"); 
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retum (null); 


} 
\//getOrderMainInfo 


public Iots.StatusStruct[] getStatus(String orderID) 
{ 

try 

{ 

Jots.StatusStruct[] states; 

Vector tempV = mylotsDB.getStatus(orderID); 

states = new lots.StatusStruct[tempV.size()]; 

tempV.copylInto(states); 

retum (states); 

} catch (Exception e) 

{ 

System.err.println("error in getStatus() IotsMedImpl"); 

retum (null); 


} 


}//getStatus 


1 //lotsMedImpl 


F. IOTSDBCLASS 


// lotsDBClass.java 

Import java.net. URL; 

Import java.util.*; 

import java.sql.*; 

public class lotsDBClass { 
Connection con; 
Driver dnver=null; 
ResultSet resultSet; 
Statement stmt; 
CallableStatement cstmt; 
PreparedStatement pstmt; 
private boolean transStatus; 
public IotsDBClass() { 

transStatus = true; 
} 
public boolean connect (String userName, String password) 
throws Exception 


| 
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boolean connectStatus = false; 
String url ="jdbc:oracle:thin:” + userName +"/" +password + 
"@computerb:1521:oracle"; 
цу 
| 
Class.forName( oracle.jdbc.driver.OracleDn ver"); 
S ystem.out.println("Connecting to ORACLE database"); 
con = DriverManager.getConnection(url); 
connectStatus = true; 
} catch (Exception e) 
{ System.out.printIn("System Exception in connect"); 
System.err.printin(e); 
throw e; 
} 
return connectStatus; 
}//connect 
public void addCustomer( [ots.customerStruct cusStruct) 


| 


try { 
stmt = con.createStatement(); 
String addsql = 


"insert into customer " + 
"values(”+ cusStruct.customerID +","+ 


и я: 


cusStruct.name d Е 


"ж 


cusStruct.bStreet в = 


и я! 


cusStruct.bCity lens icta 


"2 м! 


cusStruct.bState te art 


"э эн 


cusStruct.bZipCode +"’,”'+ 


"2? я! 


cusStruct.sStreet +" "+ 
cusStruct.sCity а = 


"Ж" 


cusStruct.sState +" "+ 


12 > 


cusStruct.sZipCode +" "+ 


27! 


cusStruct.telephone +"","+ 


ия! 


cusStruct.phax TEE 


нэ я! 


cusStruct.email 7 


поя! 


cusStruct.creditCardNo +", + 
cusStruct.expDate +" "+ 
cusStruct.creditCardType +"?" ; 
stmt.execute Update (addsq]), 
} catch (Exception e) 


| 


System.err.println(" Error in IotsDBClass addcustomer()" 4e); 


} 


164 


W/addCustomer 
public void modCustomer( Iots.customerStruct cusStruct) 
{ 
try { 
stmt = con.createStatement(); 
String modsq] = "update customer " + 
"set CustomerName =” + cusStruct.name i. i 


2 


к”. 

" ResAddrStreet =" + cusStruct.bStreet +"""+ 
+ 

+ 


" ResAddrCity ™ + cusStruct.bCity 
" ResAddrState =" + cusStruct.bState 
" ResAddrZip =” +cusStruct.bZipCode +"’,"+ 
" ShipAddrStreet =" + cusStruct.sStreet +", + 
" ShipAddrCity ™ + cusStruct.sCity +, + 
" ShipAddrzState =" + cusStruct.sState +", 
" ShipAddrZip =" +cusStruct.sZipCode +"’,"+ 
TelephoneNumber =" + cusStruct.telephone +" "+ 
FaxNumber = " + cusStruct.phax Tr 
" EmailAddress =” + cusStmict.email HUC 
CreditCardNumber = ™ + cusStruct.creditCardNo +","+ 
CreditCardExpDate= ™ + cusStruct.expDate  +™,"+ 
" CreditCardType =” + cusStruct.creditCardTypet+"’ "+ 
"where CustomerID <=" +cusStruct.customerID +"; 
stmt.executeUpdate (modsq]); 
} catch (Exception e) 
{ 
System.err.printIn("Error in JotsDBClass modcustomer()"+e); 
\//modCustomer 
public Iots.customerStruct getCustomer( String cusID) 
{ 
Jots.customerStruct cusStruct = null; 
try { 
stmt = con.createStatement(); 
String getsql = "select * from customer " + 
“where CustomerID = ” + cusID +"”; 
ResultSet res = stmt.executeQuery(getsql); 
ге$.пех1(); 
cusStruct = new lots.customerStruct 
(res.getString(1), res.getString(2), 
res.getString(3), res.getString(4), 
res.getString(5), res.getString(6), 
res.getString(7), res.getString(8), 
res.getString(9), res.getString(10), 


165 


res.getString(11), res.getString(12), 
res.getString(13), гез. ге У шпо(14), 
res.getString(15), res.getString(16) 
y: 

) catch (Exception e) 

| 

S ystem.err.println("Error in IotsDBClass getCustomer()" e); 
} 
return(cusStruct); 
V/getCustomer 


public void addWarehouse( Iots.warehouseStruct wareStruct) 


| 


try { 
stmt = con.createStatement(); 
String addsql = 


"insert into WAREHOUSE " + 
"values(”+ wareStruct.sWarehouselD +"”," 


"эон 


wareStruct.sWarehouseName +","+ 


wareStruct.sWareAddrStreet +"*””+ 
wareStruct.sWareAddrCity +", "+ 
wareStruct.sWareAddrState +"’,"'+ 
wareStruct.sWareAddrZip +", + 


ft? >» 


wareStruct.sFaxNumber +","+ 
wareStruct.sTelephoneNumber +">" ; 
stmt.executeUpdate (addsa]l); 
} catch (Exception e) 


| 


System.err.println("Error in lotsDBClass addWarehouse()"-+e); 
| 
}//addW arehouse 
public void mod Warehouse( Iots.warehouseStruct wareStruct) 


| 
try | 
stmt — con.createStatement(); 
String modsql = "update WAREHOUSE + 


+ 


"set WarehouseName = ”™ + wareStruct.sWarehouseName +"’,"+ 
" WareAddrStreet = " + wareStruct.sWareAddrStreet +" "+ 
"  WareAddrCity ="” + wareStruct.sWareAddrCity TUS. 
" WareAddrState = " + wareStruct.sWareAddrState +" "+ 

THUS. 


"  WareAddrZip =>” + wareStruct.sWareAddrZip | 
" БахМшпбег =” + wareStruct.sFaxNumber го 
TelephoneNumber= " + wareStruct.sTelephoneNumber+""+ 
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"mo. 
, 


" where WarehouselD = ” + wareStruct.sWarehouseID + 
stmt.executeUpdate (modsq]); 
y catch (Exception e) 
{ 
System.err.printin(" Error in IotsDBClass modWarehouse()"+e); 
} 
\//modW arehouse 
public Iots.warehouseStruct get Warehouse( String warelD) 
{ 
Iots.warehouseStruct wareStruct = null; 
try { 
stmt = con.createStatement(); 
String getsql = "select * from WAREHOUSE " + 
"where WarehouselD = ™ + wareID +"”: 
ResultSet res = stmt.executeQuery(getsql); 
res.next(); 
wareStruct = new lots.warehouseStruct 
(res.getString(1), res.getString(2), 
res.getString(3), res.getString(4), 
res.getString(5), res.getString(6), 
res.getString(7), res.getString(8) 
|| 
} catch (Exception e) 
{ 
System.err.printIn( Error in lotsDBClass get W arehouse()"+e); 
) 
retum(wareStruct); 
\//getW arehouse 


public Iots.balanceStruct getBalance( String itemID, String warelD) 
{ 
Iots.balanceStruct balStruct = null; 
try | 
stmt = con.createStatement(); 
String getsql = "select ItemID, ItemDescreption, PartNumber, " + 
" Taxableltem, SalePrice, UnitOfSale, WarehouseID,WarehouseName, "+ 
" Balance, ReorderLevel, ReorderQty " 4 
" from item, inventory, warehouse " + 
" where ItemID = " + itemID +"" AND ItemID = ItemID_FK AND" + 
" WarehouselD= ” + wareID +"’ AND WarehouseID=WarehouseID_FK"; 


ResultSet res= stmt.executeQuery(getsq]); 
res. next(); 
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balStruct = new lots.balanceStruct 
(res.getString(1), res.getString(2), 
res.getString(3), res.getString(4), 
res.getFloat(5), res.getString(6), 
res.getString(7), res.getString(8), 
res.getFloat(9), res.getFloat(10), 
res.getFloat(11) 
ү 
} catch (SQLException ex) 
{ 
System.err.printin("Error in lotsDBClass getBalance()"); 
while (ex !=null) 1 
System.out.printIn("SQLState: " + ex.getSQLState()); 
S ystem.out.println(" Message : " +ex.getMessage()); 
S ystem.out.printIn(" VendorCo: " *ex.getErrorCode()); 
ex.printStackTrace(S ystem.out); 
ex= ex.getNextException(); 
System.out.printin( O O 
} 
} 
retum(balStruct); 
}//getBalance 
public Vector getWarelDs() 
| 
try { 
Vector warelDs = new Vector(); 
stmt = con.createStatement(); 
String getsq] = 
"select WarehouselD from Warehouse group by WarehouselD"; 
ResultSet res= stmt.executeQuery(getsq]); 
while (res.next()) { 
warelDs.addElement( new lots.IDsStruct(res.getString(1)) ); 
V//while 
retum(wareIDs); 
} catch (SQLException ex) 
{ 
System.err.println( Error in IotsDBClass getWareIDs()"); 
while (ex !=null) { 
System.out.printin(’SQLState: " + ex.getSQLState()); 
S ystem.out.println(" Message : " *ex.getMessage()); 
System.out.printIn(" VendorCo: " *ex.getErrorCode()); 
ex.printStackTrace(S ystem.out); 
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ex= ex.getNextException(); 
ОУ опера Е Tr N, 
| 


return(null); 


j 
V/getWarelDs 


public Vector getItemIDs() 
{ 
try { 
Vector itemIDs = new Vector(); 
stmt = con.createStatement(); 
String getsql = 
"select ItemID from ITEM group by ItemID"; 
ResultSet res= stmt.executeQuery(getsq]); 
while (res.next()) { 
itemIDs.addElement( new Iots.ItemIDsStruct(res.getString(1)) ); 
}//while 
return(itemIDs); 
} catch (SQLException ex) 
{ 
System.err.println("Error in IotsDBClass getItemIDs()"); 
while (ex !=null) { 
System.out.printin("SQLState: " + ex.getSQLState()); 
System.out.printin("Message : " +ex.getMessage()); 
System.out.println("VendorCo: " +ex.getErrorCode()); 
ex.printStackTrace(S ystem.out); 
ex= ex.getNextException(); 
System.out.printin(" s 
j 
return(null); 


} 
}//getItemIDs 


public Vector getltemIDs2() 
{ 
try 1 
Vector 1itemIDs2 = new Vector(); 
stmt = con.createStatement(); 
String getsql = 
"select ItemID, ItemDescreption, SalePrice from ITEM"; 
ResultSet res= stmt.executeQuery(getsql); 
while (res.nextQ)) { 
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itemIDs2.addElement( new Iots.ItemIDsStruct2 
(res.getString(1),res.getString(2), res.getFloat(3) )); 
}//while 
retum(itemIDs2); 
} catch (SQLException ex) 
{ 
System.err.printIn("Error ın IotsDBClass getltemIDs20"); 
while (ex !=null) { 
System.out.printIn( Message : " +ex.getMessage()); 
ex= ex.getNextException(); 
} 


retum(null); 


} 


}//getItemIDs2 


public Vector getTransIDs() 
| 
try { 
Vector transIDs = new Vector(); 
stmt = con.createStatement(); 
String getsq] = 
"select * from TRANSACTION"; 
ResultSet res= stmt.executeQuery(getsql); 
while (res.next()) | 
transIDs.addElement( new Iots.TransactionStruct( 
res.getString(1),res.getString(2) )); 
//while 
return(transIDs); 
} catch (SQLException ex) 
{ 
S ystem.err.println("Error in IotsDBClass getTransIDs()"); 
while (ex !=null) { 
System.out.printIn(" Message : " +ex.getMessage()); 
ex.printStackTrace(System.out); 
exsiemectNextException(); 
j 


return(null); 


| 
V/getTransIDs 


public Vector getCusIDs() 


| 
try { 
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Vector cusIDs = new Vector(); 
stmt = con.createStatement(); 
String getsql = 
"select CustomerID, CustomerName from CUSTOMER"; 
ResultSet res= stmt.executeQuery(getsq]); 
while (res.next()) { 
cusIDs.addElement( new lots.CustomeriDsStruct( 
res. getString(1),res.getString(2) )); 
\//while 
return(cusIDs); 
} catch (SQLException ex) 
{ 
System.err.println("Error in IotsDBClass getCusIDs()"); 
while (ex !=null) ( 
System.out.println(" Message : " +ex.getMessage()); 
ex.printStackTrace(System.out); 
ex= ex.getNextException(); 
} 
return(null); 


} 
V/getCusIDs 


public Iots.OrderResultStruct placeOrder( 
Iots.OrderStruct[] inOrder,lots.StatStruct stat ) 
{ 
Connection wcon = con; 
transStatus= true; 
цу { 
wcon.setAutoCommit(false); 
int invoicelD = getInvoicelD(wcon); 
int orderID = getOrderID(wcon); 
openInvoice(wcon, 
java.lang.String.valueOf(invoiceID), 
stat.sOrderDateAndTime, 
stat.sTotalDue 
); 
openInvoiceDetails(wcon, 
java.lang.String.valueOf(invoiceID), 
java.lang.String. valueOf(orderID) 
); 
openOrder(wcon, 
java.lang.String.valueOf(orderID), 
stat. sCustomerID, 
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stat.sOrderDateAndTime, 
stat.s TransactionCode, 
stat.s TaxAll, 
stat.s TotalDue, 
java.lang.String. valueOf(invoiceID) 
D: 
for ( int 120; 1< inOrder.length; 1++) 
| 
updatOrderDetails(wcon, 
java.lang.Stnng.valueOf(orderID), 
inOrder[1i].itemID, 
inOrder[i].quantity, 
inOrder[i].salePrice, 
inOrder[i |.extendedPrice 
7 
V/for 
updateOrderStatus(wcon, 
java.lang.String.valueOf(orderID), 
stat.sOrderDateAndTime, 
stat.s UserID, 
"NEW", 
"Order is placed recently" 
); 
setInvoiceID(wcon); 
setOrderID(wcon); 
if (transStatus) //all transactions completed with no errors 
wcon.commit(); 
else wcon.rollback(); 
retum(new lots.OrderResultStruct( 
java.lang.String.valueOf(orderID), 
"Please write down the order's ID for tracking purposes ")); 
) catch (Exception e) 
| 
S ystem.err.println(" Error in IotsDBClass placeOrder()" 4e); 
return(new lots.OrderResultStruct("no id av","UnSuccessful/DB ")); 


| 
)//placeOrder 


public void updateOrderStatus( 
Connection wcon, 
String  orderID, 
String sOrderDateAndTime, 
String SUserID, 


String status, 
String remarks) 


{try 
{ 
stmt = wcon.createStatement(); 
String dd =sOrderDateAndTime.substring(4,6); 
String mmm - sOrderDateAndTime.substring(0,3); 
String yy =sOrderDateAndTime.substring(10,12); 
String wdate= dd + "-" + mmm + "-" + уу; 
String getsql = "insert into ORDER_STATUS "+ 


"values (” + orderID +" TO_DATE(” + 
wdate +"), + 
sUserID +," + 
status T 
remarks +)"; 


System.out.printIn(getsq]); 

stmt.executeUpdate(getsql); 

} catch (Exception e) 

{ 
System.err.printin("Error in lotsDBClass updateOrderStatus()"+e); 
transStatus=false; 


| 
}//updateOrderStatus 


public void updatOrderDetails( 
Connection wcon, 
String orderlD, 
String itemID, 
int quantity, 
float salePrice, 
float extendedPrice) 
{try 
{ 
stmt = wcon.createStatement(); 
String getsql = "insert into ORDER_DETAILS "+ 


"values (” + 
orderID +" + 
itemID TUUS. 
quantity Tut 
salePrice Tu + 


extendedPrice +")"; 
System.out.printIn(getsq]); 
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stmt.execute Update(getsql); 

} catch (Exception e) 

{ 
System.err.printIn("Error in lotsDBClass updateOrderDetails()"+e); 
transStatus=false; 


| 
}//updateOrderDetails 


| rn 6-6-66—-—- 

public void openOrder( 
Connection wcon, 
String orderlD, 
String sCustomerlD, 
String sOrderDateAndTime, 
String  sTransactionCode, 
float sTaxAll, 
float sTotalDue, 
String invoicelD) 

{ try 

| 


stmt = wcon.createStatement(); 

String dd = sOrderDateAndTime.substring(4,6); 
String mmm = sOrderDateAndTime.substring(0,3); 
String yy = sOrderDateAndTime.substring(10,12); 
String wdate= dd + "-" + mmm + "-" + yy; 

String getsql = "insert into ORDERS "+ 


"values (” + 
orderID +", "+ 
sCustomerlD +", TO_DATEC" + 
wdate TU" + 
зТтапзаспопСоде +", + 
sTaxAll T x 


sTotalDue +","+ 
invoicelD +"”)"; 
System.out.printin(getsq]); 
stmt.executeUpdate(getsq]); 
} catch (Exception е) 
( 
System.err.printin("Error in lotsDB Class openOrder()"+e); 
transStatus=false; 


| 
}//openOrder 


public void openInvoiceDetails(Connection wcon, Stnng invoicelD, 


174 


String orderID) 
(try 

{ 
stmt = wcon.createStatement(); 
String getsql 2 "insert into INVOICE DETAILS "+ 

"values (" + invoiceID +"’,” + orderID +")"; 

System.out.printin(getsq]); 
stmt.executeUpdate(getsql); 

) catch (Exception e) 

{ 
System.err.printin("Error in lotsDBClass OpenInvoiceDetails()"+e); 
transStatus=false; 


| 


V/openInvoiceDetails 


public void openInvoice(Connection wcon, String invoicelD, 
String sOrderDateAndTime, float sTotalDue) 
{try 
{ 
stmt = wcon.createStatement(); 
String dd = sOrderDateAndTime.substring(4,6); 
Sting mmm = sOrderDateAndTime.substring(0,3); 
String yy = sOrderDateAndTime.substring(10,12); 
String wdate= dd + "-" + mmm + "-" + yy; 
String getsql = "insert into INVOICE " + 
"values (” + invoiceID +", TO_DATE(” + wdate + 
75," + зТога џе +")"; 
System.out.println(getsq]); 
stmt.executeUpdate(getsq]l); 
} catch (Exception e) 
{ 
System.err.println("Error in IotsDBClass OpenInvoiceID()"+e); 
transStatus=false; 
} 


V/openInvoice 


public int getInvoiceID(Connection wcon) 
(try 
{ 
stmt = wcon.createStatement(); 
String getsql = "select IDs from ınvoicesIDs where ikey =1"; 
ResultSet res = stmt.executeQuery(getsql); 
res.next(); 


E 


return (res.getint(1)); 
} catch (Exception e) 
| 
S ystem.err.println( Error in IotsDBClass getInvoiceID()" e); 
transStatus=false; 
return(0); 
} 


V/getinvoiceID 


public void setInvoiceID(Connection wcon) 
[try 
( 
stmt = wcon.createStatement(); 
String getsql = "update invoicesIDs set IDs 2 IDs + 1" + 
" where ıkey=1 
stmt.executeUpdate(getsql); 
) catch (Exception e) 
{ 
System.err.printin("Error ın IotsDBClass setInvoicelD()"+e); 
transStatus=false; 


| 
V//setInvoiceID 


". 
> 


public int getOrderID(Connection wcon) 
[try 
| 
stmt 2 wcon.createStatement(); 
String getsql = "select IDs from ordersIDs where okey =1"; 
ResultSet res = stmt.executeQuery(getsq]); 
res.next(); 
return (res.getInt(1)); 
) catch (Exception e) 
{ 
System.err.printIn("Error in lotsDBClass getOrderID()"+e); 
transStatus=false; 
return(0); 
} 
}//getOrderID 


public void setOrderID(Connection wcon) 
[try 
| 


stmt = wcon.createStatement(); 
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String getsql = "update ordersIDs set IDs = IDs + 1" + 
" where okey=1"; 
stmt.executeUpdate(getsql); 
) catch (Exception e) 
| 
System.err.printin("Error in IotsDBClass setOrderID()" 4e); 
transStatus=false; 


} 
V/setOrderID 


public Vector getOrderMainInfo( 
java.lang.String orderID, 
java.lang.String lDate, 
java.lang.String hDate) 
{ 
String getsql; 
try { 
Vector ordMain = new Vector(); 
stmt = con.createStatement(); 
if (orderID.compareTo("")==0) // orderID= spaces 
| 
getsql = "select * from ORDERS where OrderDateAndTime >= " + 


"TO_Date(” + Date + "% AND OrderDateAndTime <=" + 
"To_DATE(” + hDate + ">"; 
} 
else 
{ 
getsql ="select * from ORDERS where OrderID = ™ +orderID+"”; 
} 
System.out.printIn(getsql); 
ResultSet res= stmt.executeQuery(getsql); 
while (res.next()) { ordMain.addElement( new Jots.OrderMainInfoStruct( 
res. getString(1),res.getString(2), res.getString(5), 
res.getString(6),res.getString(3), res.getString(7), 
getLastStatus(res.getString(1)) )); 
V/while 


return(ordMain); 
) catch (SOLException ex) 
{ 


System.err.printin("Error in IotsDBClass getOrderMainInfo()"); 
while (ex !=null) { 


System.out.printiIn("Message : " +ex); 
ex= ex.getNextException(); 
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retum(null); 


) 
}//getOrderMainInfo 


public String getLastStatus(java.lang.String orderID) 
{ 
String str =null; 
try { 
String getsql; 
stmt = con.createStatement(); 
getsql =" SELECT Status” + 
"from ORDER_STATUS where OrderID_FK = ™ +orderID+"”; 
System.out.printin(getsql); 
ResultSet res= stmt.executeQuery(getsq]l); 
while (res.next()) { 
str = res.getString(1); 
}//while 
return(str); 
} catch (SQLException ex) 
{ 
System.err.printIn("Error in lotsDBClass getLastStatus()”); 
while (ex !=null) { 
System.out.printIn(" Message : " +ех); 
ex= ex.getNextException(); 
| 
return(new String("Not Found")); 


| 


V/getLastStatus 


public Vector getStatus(java.lang.String orderID) 
[ 
try { 
String getsal; 
Vector ordstat = new Vector(); 
stmt = con.createStatement(); 
getsql ="select StatusDateAndTime, Status, Remarks " + 
" from ORDER. STATUS where OrderID FK = ™ +orderID+""; 
System.out.println(getsql); 
ResultSet res= stmt.executeQuery(getsq]l); 
while (res.next()) ( ordstat.addElement( 
new lots.StatusStruct( 
res.getString(1),res.getString(2), res.getString(3) )); 
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V/while 
return(ordstat); 
} catch (SQLException ex) 
{ 
System.err.printIn("Error in lotsDBClass getStatus()”); 
while (ex !=null) { 
System.out.printIn("Message : " +ex); 
ex= ex.getNextException(); 
} 
retum(null); 
} 
V/getStatus 
V/IotsDBClass 


G. SECURITYBEAN 


//SecuntyBean.java 
import java.awt.*; 
import java.awt.Graphics; 
import java.util.*; 
import java.awt.event.*; 
import javax.swing.*; 
import java.lang.String; 
import org.omg.CosNaming.*; 
import org.omg. CORBA.*; 
public class SecurityBean extends JPanel ( 
private Iots.lotsDispenser myDispenser; 
private JPanel pl; 
private Graphics gContext; 
private JLabel userL, passwordL,dummyL; 
private JTextField user, status; 
private JPasswordField password; 
private JButton logOnb; 
private GridBagLayout ebLayout; 
private GridBagConstraints gbConstraints; 
private Iots.IotsMed mylotsMed; 
public SecurityBean(Iots.IotsMed inMed, 
lots.lotsDispenser myDisp) { 
mylotsMed= inMed; 
myDispenser= myDisp; 
gbLayout = new GridBagLayout(); 
setLayout(gbLayout); 
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gbConstraints = new GndBagConstraints(); 
dummyL = new JLabel (" "); 
userL = пем JLabel ("User ID"); 
passwordL = new JLabel ("Password"); 
user znewJlextEield( 15): 
password = new JPasswordField("",15); 
status = new JTextField("" 30); 
status.setEditable(false); 
logOnb z new JButton("Logon"); 
logOnb.addActionListener(new ActionListener() 
{ 
public void actionPerformed(ActionEvent event) { 
try { 
if (mylotsMed.connect(user.getText(), 
password. getText())) 
{ 
Status.setText("Access 1s Autherized for user=" + 
user.getText()); 
} 
else { 
status.setText( NOT Autherized. Check" + 
" UserID and/or Pasword are valid"); 
//terminate the connection 
myDispenser.releaseObject(mylotsMed); 


) 
} 


catch (Exception ex) { 
status.setText(" Exception ın SecurityBean " +ex); 


| 
| 

} ); 
gbConstraints.fill= GndBagConstraints. NONE; 
gbConstraints.anchor=GndBagConstraints. NORTHWEST, 
addComponent(dummyL,0,0,1,1); 
addComponent(dummyL, 1,0, 1,1); 
addComponent(dummyL,2,0,1,1); 
addComponent(userL, 3,0,1,1); 
addComponent(user , 3,1,1,1); 
addComponent(passwordL,4,0,1,1); 
addComponent(password ,4,1,1,1); 
gbConstraints.fill = GndBagConstraints. NONE; 
addComponent(logOnb ,5,0,2,1); 
addComponent(status ,6,0,2,1); 


180 


set Visible(true); 

}// constructor 

private void addComponent( Component c, int row, 

int column, int width, int height) { 

ebConstraints.gridx = column; 
ebConstraints.gridy = row; 
ebConstraints.gndwidth= width; 
ebConstraints.gridheight- height; 
ebLayout.setConstraints(c, gbConstraints); 
add(c); 

}//addComponent 

V/SecuntyBean 


H. WAREHOUSEINFOBEAN 


//'WarehouseInfoBean.java 
import java.awt.*; 
import java.util.*; 
import java.awt.event.*; 
import javax.swing.*; 
import java.lang.String; 
import org.omg.CosNaming.*; 
public class WarehouseInfoBean extends JPanel | 
private JPanel pl; 
private JLabel warehouseIDL, warehouseNameL, 
wareAddrL, wareAddrStreetL, 
wareAddrCityL, wareAddrStateL, wareAddrZipL, 
seperatorL,fax NumberL,telephoneNumberL; 
private JTextField 
warehouselD, warehouseName, wareAddrStreet, 
wareAddrCity, wareAddrZip, 
seperator,fax Number,telephoneNumber, status; 
private String [] states = 
{"" "AL","AK",“AR","AZ","CA" 3€OmC Te DE, DG. 
"СА","НГ" "Го" "Ш," ОМ" ТА" "КО" "КУ" "БА" "МЕ", 
"MD'","MA","MI","MN'","MS","MO","MT","NE","NV","NH", 
"NJ',NM',"NY","NC","ND'","OH",OK","OR","PA","RI', 
"SCT SD" IN’, TX’, Ue vr. vA WA WV WI, 


"WY" \ : 
private JComboBox wareAddrState; 
private JButton addWareb, getWareb, update Wareb; 


private GridBagLayout gbLayout; 
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pnvate GndBagConstraints gbConstraints; 

private Iots.warehouseStruct wareStruct: 

private Iots.IotsMed mylotsMed; 

public WarehouseInfoBean(Iots.IotsMed inMed) ( 
mylotsMed= ınMed; 
gbLayout = new GndBagLayout(); 
setLayout(gbLayout); 
gbConstraints = new GndBagConstraints(); 
warehouseIDL = new JLabel ("Warehouse ID"); 
warehouseNameL = new JLabel ("Name"); 
wareAddrL = new JLabel ("Address"); 
wareAddrL.setForeground(java.awt.Color.red); 
wareAddrStreetL = new JLabel("Street"); 
wareAddrCityL = new JLabel("City"); 
wareAddrStateL = new JLabel(" State"); 
wareAddrZipL = new JLabel("Zip Code"); 
seperatorL =newJLabel("________"); 
faxNumberL = new JLabel("Fax"); 
telephoneNumberL- new JLabel("Telephone"); 
warehouselD  =new JTextField("",5): 
warehouseÑame =new JTextField("",25),; 
wareAddrStreet = new JTextField("",25); 
wareAddrCity = пем JTextField("",15); 
wareAddrState - new JComboBox(); 
for (int 1=0; 1< states.length; i++) { 

wareAddrState.addltemístates[1]); 

\//for 
wareAddrZip = new JTextField("",10); 
fax Number = new JTextField ie): 
telephoneNumber = new JTextField("",12); 


Status = new JTextField("",40); 

addWareb = new JButton(" Add Warehouse"); 
addWareb.setForeground(java.awt.Color.red); 
getWareb = new JButton("Get Warehouse"); 


getWareb.setForeground(java.awt.Color.red); 
updateWareb =new JButton("Mod Warehouse"); 
update Wareb.setForeground(java.awt.Color.red); 
add Wareb.addActionListener(new ActionListener() 


{ 


public void actionPerformed(ActionEvent event) { 
try { 


"" 


status.setT'ext(""); 
wareStruct = new lots.warehouseStruct( 
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warehouselD.getText(), 
warehouseName.getText(), 
wareAddrStreet.getText(), 
wareAddrCity.getText(), 
java.lang.String.valueOf(wareAddrState.getSelectedltem()), 
ware AddrZip.getText(), 
faxNumber.getText(), 
telephoneNumber. getText() 
ү 
mylotsMed.addWarehouse(wareStruct); 
} 
catch (Exception ex) { 
status.setText("Exception AddWarehouse: " +ex.toString()); 


} 
} 
m: | 
getWareb.addActionListener(new ActionListener() 


| 


public void actionPerformed(ActionEvent event) | 
try { 


status.setText(" "); 
wareStruct 2 mylotsMed.getW arehouse(warehouseID.getText()); 
warehouseID.setText(wareStruct.sW arehouseID); 
warehouseName.setText(wareStruct.sWarehouseName); 
wareAddrStreet.setText(wareStruct.s WareAddrStreet); 
ware AddrCity.setText(wareS truct.sWareAddrCity); 
wareAddrState.setSelectedltem(wareStruct.sWareAddrState); 
wareAddrZip.setText(wareStruct.sWareAddrZip); 
faxNumber.setText(wareStruct.sFaxNumber); 
telephoneNumber.setText(wareStruct.sTelephoneNumber); 
} 
catch (Exception ex) { 
status.setText("Exception getWarehouse: " +ex.toString()); 
} 
} + 
|); 
updateWareb.addActionListener(new ActionListener() 
{ 
public void actionPerformed(ActionEvent event) { 
try { 
status.setText(""); 
wareStruct = new lots. warehouseStruct( 
warehouselD.getText(), 
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warehouseName.getText(), 
wareAddrStreet.getText(), 
wareAddrCity.getText(), 
java.lang.String.valueOf(wareAddrState.getSelectedItem()), 
wareAddrZip.getText(), 
faxNumber.getText(), 
telephoneNumber.getText() 
Jj: 
mylotsMed.modW arehouse(wareStruct); 
| 
catch (Exception ex) { 
status.setText( "Exception modWarehouse: " +ex.toString()); 


| 
j 
} ); 

ebConstraints.f11l = GndBagConstraints. NONE; 
gbConstraints.anchor=GndBagConstraints. NORTHWEST; 
addComponent(warehouseIDL,0,0,1,1); 
addComponent(warehouselD, 0,1,1,1); 
addComponent(warehouseNameL,0,2,1,1); 
addComponent(warehouseName,0,3,2,1); 
addComponent(wareAddrL,2,0,1,1); 
addComponent(getWareb,7,3,1,1); 
addComponent(add Wareb,8,3,1,1); 
addComponent(updateW areb,9,3,1,1); 
addComponent(wareAddrStreetL,3,0, 1,1); 
addComponent(wareAddrStreet, 3,1,3,1); 
addComponent(wareAddrCityL,4,0,1,1); 
addComponent(wareAddrCity,4,1,1,1); 
addComponent(wareAddrStateL,5,0,1,1); 
addComponent(wareAddrState,5,1,1,1); 
addComponent(wareAddrZipL,6,0,1,1); 
addComponent(wareAddrZip,6,1,1,1); 
addComponent(seperatorL,7,0,1,1); 
addComponent(fax NumberL,8,0,1,1); 
addComponent(faxNumber,8,1,1,1); 
addComponent(telephoneNumberL,9,0,1,1); 
addComponent(telephoneNumber,9,1,1,1); 
addComponent(status,10,0,6,1); 
set Visible(true); 

\// constructor 

private void addComponent( Component c, int row, int column, int width, 

int height) { 
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gbConstraints.gndx = column; 
ebConstraints.gridy — row; 
ebConstraints.gndwidth= width; 
ebConstraints.gridheight= height; 
gbLayout.setConstraints(c, gbConstraints); 
add(c); 

V/WarehouseInfoBean 


I. CUSTOMERBEAN 


/NotsLSMsBean.java 
import java.awt.*; 
import java.util.*; 
import java.awt.event.*; 
import javax.swing.*; 
import java.lang.String; 
import org.omg.CosNaming.*; 
public class CustomerBean extends JPanel | 
private JPanel pl; 
private JLabel customerIDL, nameL, bAddressL, bStreetL, 
bCityL, bStateL, bZipCodeL, sAddressL, 
sStreetL, sCityL, sStateL, sZipCodeL, 
seperator,telephoneL, phaxL, emailL, 
creditCardNoL, expDateL, creditCardTypeL, myL; 
private JTextField 
customerID, name, bStreet, bCity, bZipCode, sStreet, 
sCity, sZipCode, telephone, phax, email, creditCardNo, 
status; 
private String [] states — 
[" “АБА ТАК САК ,А2", СА" "СО" "СТ", БВ" EL”, 
"СА, НГ, №, Ш ЛА, К. КУ ТА Vis 
"МО","МА" "МГ" "ММ" "М$" "МО" "МТ" "МЕ" "МУ" "МН", 
"NIJ", "NM УМУ ИМЕ ND. CH, OK OR SEA RT 
"SC" "SD IN, Pel VE VAN м. 
"ү"; 
private String [] months = {" ","JAN","FEB","MAR","APR","MAY","JUN", 
“ДИЛ, АШС SEP OCT NOV ние 
private JComboBox bState,sState,expMM,exp Y Y creditCardType; 
private JPanel  datePanel; 
private JButton addCustomerb, getCustomerb, updateCustomerb; 
private GridBagLayout gbLayout; 
private GridBagConstraints gbConstraints; 
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private lots.customerStruct cusStruct; 

private lots.lotsMed mylotsMed; 

public CustomerBean(lots.lotsMed inMed) ( 
mylotsMed= inMed; 
gbLayout = new GndBagLayout(); 
setLayout(gbLayout); 
ebConstraints 2 new GridBagConstraints(); 
customerIDL = new JLabel ("Customer ID"); 
nameL = new JLabel ("Name"); 
bAddressL = new JLabel("Billing Address"); 
bAddressL.setForeground(java.awt.Color.red); 
bStreetL - new JLabel(" Street"); 
bCityL = new JLabel("City"); 
bStateL = new JLabel("State"); 
bZipCodeL =new JLabel("Zip Code"); 
sAddressL = new JLabel("Shipping Address"); 
sAddressL.setForeground(java.awt.Color.red); 


sStreetL = new JLabel("Street"); 

sCityL = new JLabel("City”); 

sStateL - new JLabel(" State"); 
sZipCodeL = new JLabel("Zip Code"); 
зерегаюг  =newJLabel("__________”); 
telephoneL 2 new JLabel(" Telephone"); 
phaxL - new JLabel("Fax"); 

emailL = new JLabel("Email"); 


creditCardNoL = new JLabel("Credit Card No"); 
expDateL = new JLabel("Exp Date"); 
creditCardTypeL- new JLabel("Credit Card Type"); 


myL = new JLabel(" Month Year"); 
customerID = new JTextField("",7); 

name = new JTextField("",15); 

bStreet = new JTextField("" 15); 

bCity = new JTextField("",15); 

bState = new JComboBox(); 

sState = new JComboBox(); 


for (int 1=0; i< states.length; i++) { 
bState.addltem(states[i]); 
sState.addItem(states[1]); 

V/for 

bZipCode = new JTextField("",10); 

sStreet = new JTextField("" 15); 

sCity = new JTextField("",15); 

sZipCode = new JTextField("",10); 
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telephone 2 new JTextField("",10); 


phax = new JTextField("",10); 
email = пем ЕЕЕ Ло у: 
creditCardNo = new JTextField("",16); 
datePanel = new JPanel(); 

expMM = new JComboBox(); 
expYY = new JComboBox(); 


for (int 1=0; ¡<months.length; 1++) 
{ expMM.addlItem(monthsfi]); } 
for (int i=00; 1<20; 1++) 
{ expY Y.addItem(java.lang.String.valueOf(i)); } 
datePanel.add(expMM); 
datePanel.add(exp Y Y ); 
creditCardT ype= new JComboBox(); 
creditCardT ype.addItem(" Visa"); 
creditCardT ype.addItem(" MasterCard"); 
creditCardT ype.addItem(" Discovery"); 
status = new JTextField( ^ ",40); 
addCustomerb = new JButton(" Add Customer"); 
addCustomerb.setForeground(java.awt.Color.red); 
getCustomerb = new JButton("Get Customer"); 
getCustomerb.setForeground(java.awt.Color.red); 
updateCustomerb = new JButton("Mod Customer"); 
updateCustomerb.setForeground(java.awt.Color.red); 
addCustomerb.addActionListener(new ActionListener() 
{ 
public void actionPerformed(ActionEvent event) { 
try { 
status.setText(""); 
cusStruct = new lots.customerStruct( 
customerlD.getText(), 
name.getText(), 
bStreet.getText(), 
bCity.getText(), 
java.lang.String. valueOf(bState. getSelectedItem()), 
bZipCode.getText(), 
sStreet.getText(), 
sCity.getText(), 
java.lang.String. valueOf(sState. getSelectedltem()), 
sZipCode.getText(), 
telephone.getText(), 
phax.getText(), 
email.getText(), 
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creditCardNo.getText(), 
as Е 
java.lang.String. valueOf(expMM. getSelectedItem()) + 
ин + 
java.lang.String.valueOf(expY Y.getSelectedltem()), 
java.lang.String. valueOf(creditCardType.getSelectedItem()) 
); 
mylotsMed.addCustomer(cusStruct); 
} 
catch (Exception ex) { 
status.setText(" Exception AddCustomer: " +ex.toString()); 


| 
| 
m 
getCustomerb.addActionListener(new ActionListener() 
{ 
public void actionPerformed(ActionEvent event) { 
try { 
status.setText(" "); 
cusStruct 2 mylotsMed.getCustomer(customerID.getText()); 
customerID.setText(cusStruct.customerID); 
name.setText(cusStruct.name); 
bStreet.setText(cusStruct.bStreet); 
bCity.setText(cusStruct.bCity); 
bState.setSelectedItem(cusStruct.bState); 
bZipCode.setText(cusStruct.bZipCode); 
sStreet.set Text(cusStruct.sStreet); 
sCity.setText(cusStruct.sCity); 
sState.setSelectedItem(cusStruct.sState); 

sZipCode.setText(cusStruct.sZipCode); 
telephone.setText(cusStruct.telephone); 
phax.setText(cusStruct.phax); 
email.setText(cusStruct.email); 
creditCardNo.setText(cusStruct.creditCardNo); 


char [] datechar = (cusStruct.expDate).toCharArray(); 

String mm = Java.lang.String.copyValueOf(datechar, 5,2); 

int mmi= java.lang.Integer.parselnt(mm); 

expMM.setSelectedltem(months[mmi)); 

String yy = java.lang.String.copyValueOf(datechar, 2,2); 

int’ yyi=java.lang.Integer.parseInt(yy); 

exp Y Y.setSelectedItem(java.lang.Stnng. valueOf(yy1)); 
creditCardT ype.setSelectedItem(cusStruct.creditCardT ype); 
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} 


catch (Exception ex) { 
status.setlext("Exception getCustomer: " *ex.toString()); 
} 
} 
m 
updateCustomerb.addActionListener(new ActionListener() 


{ 


public void actionPerformed(ActionEvent event) { 
try į 
status.setText(""); 
cusStruct = new Iots.customerStruct( 
customerlD.getText(), 
name.getText(), 
bStreet.getText(), 
bCity.getText(), 
java.lang.String.valueOf(bState.getSelectedItem()), 
bZipCode.getText(), 
sStreet.getText(), 
sCity.getText(), 
java.lang.String.valueOf(sState.getSelectedItem()), 
sZipCode.getText(), i 
telephone.getText(), 
phax.getText(), 
email.getText(), 
java.lang.String.copy ValueOf ( 
((creditCardNo.getText()).toCharArray()),0,16), 
"28-" + 
java.lang.String. valueOf(expMM.getSelectedItem()) + 
"-" + 
java.lang.String.valueOf(expY Y .getSelectedItem()), 
java.lang.String.valueOf(creditCardT ype.getSelectedItem()) 
); 
mylotsMed.modCustomer(cusStruct); 
} 
catch (Exception ex) { 
status.setText(" Exception modCustomer: " +ex.toString()+cusStruct); 
| 
) 


} ); 
gbConstraints.fill = GndBagConstraints. NONE; 


gbConstraints.anchor=GndBagConstraints. NORTHWEST; 
addComponent(customerIDL,0,0, 1,1); 
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addComponent(customerID, 0,1,1,1); 
addComponent(getCustomerb,0,2,1,1); 
addComponent(nameL,0,3,1,1); 
addComponent(name,0,4,3,1); 
addComponent(bAddressL,2,0,1,1); 
addComponent(addCustomerb,2,2,1,1); 
addComponent(updateCustomerb,3,2, 1,1); 
addComponent(bStreetL, 3,0, 1,1); 
addComponent(bStreet, 3,1,3,1); 
addComponent(bCityL, 4,0, 1,1); 
addComponent(bCity,4,1,1,1); 
addComponent(bStateL,5,0, 1,1); 
addComponent(bState,5,1,1,1); 
addComponent(bZipCodeL,6.0, 1,1); 
addComponent(bZipCode,6, 1,1,1); 
addComponent(sAddressL,2,4,1,1); 
addComponent(sStreet, 3,4,3,1); 
addComponent(sCity,4,4,1,1); 
addComponent(sState,5,4,1,1); 
addComponent(sZipCode,6,4,1,1); 
addComponent(seperator,7,0,1,1); 
addComponent(telephoneL,8,0,1,1); 
addComponent(telephone,8,1,1,1); 
addComponent(phaxL,8,2,1,1); 
addComponent(phax,8,4,1,1); 
addComponent(emailL,9,0,1,1); 
addComponent(email,9,1,3,1); 
addComponent(myL,9,3,2,1); 
addComponent(creditCardNoL, 10,0,1,1); 
addComponent(creditCardNo,10,1,1,1); 
addComponent(expDateL,10,2,1,1); 
addComponent(datePanel, 10,3,2,1); 
addComponent(creditCardTypeL,11,0,1,1); 
addComponent(creditCardType,11,1,1,1); 
addComponent(status,12,0,6,1); 
set Visible(true); 

\// constructor 

private void addComponent( Component c, int row, int column, int width, 

int height) { 

ebConstraints.gridx = column; 
ebConstraints.gndy = row; 
ebConstraints.gndwidth= width; 
ebConstraints. gndheight= height; 
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ebLayout.setConstraints(c, gbConstraints); 
add(c); 

}//addComponent 

\//AddCustomerBean 


J: PLACEORDERBEAN 


//PlaceOrderBean.java 

import java.awt.”; 

import java.util.*; 

import java.awt.event.*; 

import javax.swing.*; 

import java.lang.String; 

import org.omg.CosNaming.*; 

import org.omg.CORBA .*; 

public class PlaceOrderBean extends JPanel { 

private JPanel pl; 

private Iots.TransactionStruct[] transIDs; 

private Iots.CustomerIDsStruct[] cusIDs; 

private Iots.ItemIDsStruct2[] | itemIDs2; 

private lIots.OrderResultStruct ordRes; 

private lots.StatStruct Stat; 

private String userlD; 

private JLabel customerIDL, transactionCodeL,dateL, 
itemIDL, itemDescreptionL, quantityL,salePriceL, 
extendedPriceL, taxL,totalL, dummyL, orderIDL; 

private JTextField 
customerName, 
transactionDesc, orderDateAndTime, 
itemDescreption, quantity,salePrice, 
extendedPrice, tax, total,orderID, 


status; 
private JButton addToCart, deleteFromCart, submit; 
private JComboBox customerID, transactionCode, itemID; 
private JScrollPane ]5р; 


private GridBagLayout ebLayout; 

private GndBagConstraints gbConstraints; 

private Iots.IotsMed mylotsMed; 

private float wextendedPrice, taxf, totalf,wsalePrice, allTotal; 
private int quantityint; 

private Vector headers Vec, detailsVec, row Vec; 
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public PlaceOrderBean(lots.lotsMed inMed) ( 
mylotsMed= inMed; 
gbLayout = new GndBagLayout(); 
setLayout(gbLayout); 
ebConstraints = new GridBagConstraints(); 
userID ="Userl"; 
headersVec = new Vector(); 
headers Vec.addElement("Item ID"); 
headers Vec.addElement("Desc"); 
headers Vec.addElement(" Qty"); 
headersVec.addElement("U Price"); 
headers Vec.addElement(" Ex. Price"); 
headers Vec.addElement(" Tax"); 
headers Vec.addElement("Total($)"); 
allTotal = 0.0f; 
A A A 


dummyL = new JLabel (str); 

dummyL.setFore ground((java.awt.Color.magenta).darker()); 
customerIDL =new JLabel ("Customer ID"); 

customerID = new JComboBox(); 


transactionCodeL = new JLabel ("Transaction"); 
transactionCode = new JComboBox(); 
dateL = new JLabel("Date&Time"); 
orderDateAndTime = new JTextField("",12); 
orderDateAndTime.setEditable(false); 
eistomer Name №= new JTextkiela 20) 
customerName.setEditable(false); 
itemDescreption = new JTextField("",10); 
itemDescreption.setEditable(false); 
transactionDesc = new JTextField("" 20); 
transactionDesc.setEditable(false); 


itemIDL = new JLabel ("Item ID"); 
itemDescreptionL = new JLabel ("Desc "); 
quantityL = new JLabel ("Qty "); 


salePriceL = new JLabel ("U_Price "); 
extendedEnceL = new JLabel ("Ex price”); 


ХІ. = пем аре Tax): 

(оға = new JLabel ("Total Due$"); 
orderIDL = new JLabel ("Order ID :"); 
itemID = new JComboBox(); 
quantity = new JTextField ("1",5); 


Saleh mes - new JTextField (7,8); 
salePrice.setEditable(false ); 
extendedPrice = new JTextField ("",8); 
extendedPrice.setEditable(false); 


tax = new JTextField ("",8); 
tax.setEditable(false); 
total = new JTextField ("",8); 


total.setEditable(false); 

total .setForeground(java.awt.Color.red); 

orderID = new JTextField ("",8); 
orderID.setEditable(false); 
orderID.setForeground(java.awt.Color.red); 
addToCart = new JButton("Add To Cart"); 
addToCart.setForeground(java.awt.Color.red); 
deleteFromCart = new JButton(" Delete From Cart"); 
deleteFromCart.setForeground(java.awt.Color.red); 


submit = new JButton("Submit Order"); 
submit.setForeground(java.awt.Color.red); 
Status = new JTextField("",20); 


status.setEditable(false); 


try | 
transactionDesc.setText(""); 
transIDs 2 mylotsMed.getTransIDs(); 
orderDateAndTime.setText(mylotsMed.getDate()); 
for (int 1=0; 1< transIDs.length; 1++){ 
transactionCode.addltem(transIDs[i].sTransactionCode)); 
\//for 


catch (Exception ex) { 
transactionDesc.setText("Error"); 


} 


transactionCode.addActionListener(new ActionListener() 


{ 
public void actionPerformed(ActionEvent event) { 
try 1 
transactionDesc.setText( 
transIDs[transactionCode.getSelectedIndex()].sTransactionDesc); 
} 
catch (Exception ex) { 
transactionDesc.setText("Not able to refresh"); 
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try | 
customerName.setText(""); 
cusIDs 2 mylotsMed.getCusIDs(); 
for (int 1=0; i< cusIDs.length; 1++){ 
customerID.addItem(cusIDs[i].sCustomerID); 
V/for 
} 
catch (Exception ex) { 
customerName.setText("Error"); 
} 


customerID.addActonListener(new ActionListener() 


public void actionPerformed(ActionEvent event) | 
try | 
customerName.setText( 
cusIDs[customerID. getSelectedIndex()].sCustomerName); 


) 


catch (Exception ex) { 
customerName.setText("Not able to refresh"); 


try { 
itemDescreption.setText(""); 
itemIDs2 = mylotsMed.getltemIDs20(); 
for (int 1=0; i< itemIDs2.length; i++) { 
itemID.addItem(itemIDs2[i].sItemID); 
}//for 
) 
catch (Exception ex) { 
itenDescreption.setText(" Error"); 


} 
itemID.addActionListener(new ActionListener() 
{ 
public void actionPerformed(ActionEvent event) { 


try { 
itemDescreption.setText( 
itemIDs2[itemID.getSelectedIndex()].sItemDescrepton); 
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wsalePrice = 
itemIDs2[itemID. getSelectedIndex()].sSalePrice; 
quantityint = java.lang.Integer.parseInt(quantity.getText()); 
salePrice.setText( 
java.lang.String. valueOf(wsalePrice)); 


wextendedPnice = 

(itemIDs2[itemID.getSelectedIndex()].sSalePrice) * 
(quantityint); 

extendedPrice.setText(Java.lang.String. valueOf(wextendedPrice)); 

taxf = wextendedPrice * 0.07f; 

tax.setText(Java.lang.String.valueOf(taxf)); 

totalf = wextendedPnice + taxf; 

total.setText(Java.lang.String.valueOf(allTotal)); 

j 

catch (Exception ex) | 

itemDescreption.setText( Not able to refresh Names"); 


} 
m 


quantity.addActionListener(new ActionListener() 


| 


public void actionPerformed(ActionEvent event) { 
ШУ 
wsalePrice = 
itemIDs2[itemID.getSelectedIndex()].sSalePrice; 
salePrice.setText( 
java.lang.String. valueOf(wsalePrice)); 
quantityint =(java.lang.Integer.parselnt(quantity.getText())); 
wextendedPrice = 
(itemIDs2[itemID.getSelectedIndex()].sSalePnce) * 
(quantityint); 
extendedPnrice.setText(Java.lang.String.valueOf(wextendedPrice)); 
taxf = wextendedPrice * 0.07f; 
tax.setText(Java.lang.String.valueOf(taxf)); 
totalf = wextendedPrice + taxf; 
total.setText(java.lang.String.valueOf(allTotal)); 
j 
catch (Exception ex) { 
itemDescreption.setText("not able to do Quantity chang effect"); 


} 
} 
m 
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addToCart.addActionListener(new ActionListener() 


| 


public void actionPerformed(ActionEvent event) | 


try { 
status.setText( Adding to cart.."); 
rowVec  znew Vector(); 


row Vec.addElement( 
java.lang.String. valueOf(itemID.getSelectedItem())); 
rowVec.addElement(itemDescreption.getText()); 
row Vec.addElement(new Integer(quantityint)); 
row Vec.addElement(new Float(wsalePrice)); 
row Vec.addElement(new Float(wextendedPnice)); 
row Vec.addElement(new Float(taxf)); 
row Vec.addElement(new Float(totalf)); 
allTotal = allTotal + totalf; 
total.setText(java.lang.String.valueOf(allTotal)); 
detailsVec.addElement(row Vec); 
JTable jt = new JTable(details Vec,headers Vec); 
jsp =new JScrollPane(jt); 
ebConstraints.fill = GridBagConstraints. BOTH; 
addComponent(jsp ,7,0,7,3); 
gbConstraints.fill = GridBagConstraints. NONE; 
updateUI(); 


catch (Exception ex) | 
status.setText( Exception Add to cart" ex); 


deleteFromCart.addActionListener(new ActionListener() 


{ 
public void actionPerformed(ActionEvent event) { 

цу | 

status.setText(" Delete From cart.."); 

float wtot = 0.0f; 
for ( int i= 0; ı< (details Vec.size());i++) { 

Vector row Vec = (Vector) details Vec.elementAt(i); 

if (java.lang.String. valueOf(row Vec.elementAt(0)) == 

java.lang.String. valueOf(itemID. getSelectedItem())) 


| 


wtot = java.lang.Float.valueOf( 
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java.lang.String.valueOf(row Vec.elementAt(6))).float Value(); 
detailsVec.removeElementAt(1); 
а Тога! = ап Гога! - wtot; 
break; 
| 
\//for detailsVec 
if (detailsVec.isEmpty()) { allTotal =0;} 
total.setText(java.lang.String.valueOf(allTotal)); 
JTable jt = new JTable(detailsVec,headersVec); 
jsp =new JScrollPane(t); 
ebConstraints.fill= GridBagConstraints. BOTH; 
addComponent(jsp ,7,0,7,3); 
ebConstraints.fill = GndBagConstraints. NONE; 
updateUI(Q); 
} 
catch (Exception ex) { 
status.setlext(" Exception in delete from cart" ex); 


submit.addActionListener(new ActionListener() 
{ 
public void actionPerformed(ActionEvent event) { 
try { | 
Iots.OrderStruct[] inOrder = 
new lots.OrderStruct[detailsVec.size()]; 
float tax All = 0.0f; 
for ( int i= 0; 1< (details Vec.size());i++) { 
Vector rowVec = (Vector) details Vec.elementAt(1); 
tax All = taxAll + 
java.lang.Float.valueOf( 
java.lang.String. valueOf(row Vec.elementAt(5))).floatValueQ); 
inOrder[1] 2 new Iots.OrderStruct( 
java.lang.String.valueOf(rowVec.elementAt(0)), 
java.lang.String.valueOf(rowVec.elementAt(1)), 
java.lang.Integer.parselnt( 
java.lang.String. valueOf(row Vec.elementAt(2))), 
java.lang.Float.valueOf( 
java.lang.String.valueOf(row Vec.elementAt(3))).floatValue(), 
java.lang.Float.valueOf( 
java.lang.String. valueOf(row Vec.elementAt(4))).floatV alue(), 
java.lang.Float.valueOf( 
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java.lang.String.valueOf(row Vec.elementAt(5))).floatValue(), 
java.lang.Float.valueOf( 
java.lang.String. valueOf(row Vec.elementAt(6))).float V alue() 
р 
Y//for detailsVec 
stat = new lots.StatStruct( 
userlD, 
java.lang.String.valueOf( 
transactionCode.getSelectedltem()), 
java.lang.String.valueOf( 
customerID.getSelectedItem()), 
orderDateAndTime.getText(), 
tax All, 
allTotal 
); 
ordRes = mylotsMed.placeOrder( inOrder, stat); 
orderID.setText(ordRes.sOrderID); 
status.setText(ordRes.sMessage); 
| 
catch (Exception ex) ( 
status.setText( Sorry: Can't Submit incomplete order" tex); 


ebConstraints.fill = GndBagConstraints. BOTH; 
ebConstraints.anchor2GridBagConstraints.: NORTHWEST; 
addComponent(customerIDL  ,0,0,1,1); 
addComponent(customerlD ,0,1,1,1); 
addComponent(transactionCodeL,0,2,1,1); 
addComponent(transactionCode ,0,3,1,1); 
addComponent(dateL ,0,4,1,1); 
addComponent(orderDateAndTime,0,5,1,1); 
addComponent(customerName ,1,0,3,1); 
addComponent(transactionDesc ,1,3,4,1); » 
addComponent(itemIDL ‚ЖО, [ну 
addComponent(itemDescreptionL,2,1,1,1); 
addComponent(quantityL  ,2,2,1,1); 
addComponent(salePriceL ,2,3,1,1); 
addComponent(extendedPriceL ,2,4,1,1); 
addComponent(taxL A: 
addComponent(itemID 3,0,1,1); 
addComponent(itemDescreption ,3,1,1,1); 


198 


addComponent(quantity ЭА) 
addComponent(salePrice  ,3,3,1,1); 
addComponent(extendedPrice ,3,4,1,1); 


addComponent(tax ss): 
ebConstraints.fill = GndBagConstraints. CENTER; 
addComponent(dummyL ,4,0,7,1); 


ebConstraints.fill Z GndBagConstraints.BOTH; 
addComponent(totalL DOLT; 
addComponent(total А 
addComponent(addToCart ,5,2,1,1); 
addComponent(deleteFromCart ,5,3,2,1); 
addComponent(submit оор): 
addComponent(orderIDL ‚6,0‚1,1); 
addComponent(orderID OO: 
addComponent(status 025.1), 
set Visible(true); 

\// constructor 
private void addComponent( Component c, int row, int column, int width, 

int height) { 

ebConstraints.gridx = column; 
ebConstraints.gndy = row; 
gbConstraints.gridwidth= width; 
gbConstraints.gridheight= height; 
gbLayout.setConstraints(c, gbConstraints); 
add(c); 

}//addComponent 

}//PlaceOrderBean 


L: TRACKORDERBEAN 


//TrackOrderBean.java 
import java.awt.*; 
import java.util.*; 
import java.awt.event.*; 
import javax.swing.*; 
import java.lang.String; 
import org.omg.CosNaming.*; 
import org.omg.CORBA.*; 
public class TrackOrderBean extends JPanel { 
private JPanel mainPl, detailsPl, statusPl,IDatePl,hDatePl; 
// private Iots.TransactionStruct[) transIDs; 
private JLabel | orderIDL, lDateL,hDateL, ınstL1,instL2, orderIDcL; 
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private JTextField orderID, status; 
private JButton trackOrder, getOrdrDetails,getStatusDetails; 
private JComboBox orderIDc,lDateDD,lDateMMM,lDateY Y, 
hDateDD,hDateMMM,hDateY Y; 
private JScrollPane дәр; 
private String [] months = {"JAN","FEB","MAR","APR","MAY","JUN", 
"JUL" "AUG" SEP" "OCT NOV WDES: 
private GridBagLayout ebLayout; 
private GrdBagConstraints gbConstramts; 
private Iots.IotsMed mylotsMed; 
private Vector main Vec, detailsVec, statusVec, 
mainH Vec,detailsHVec,statusHVec; 


public TrackOrderBean(lots.lotsMed inMed) ( 
mylotsMed= ınMed; 
ebLayout = new GridBagLayout(); 
setLayout(gbLayout); 
gbConstraints = new GridBagConstraints(); 
mainHVec = new Vector(); 
mainH Vec.addElement("Order ID"); 
mainHVec.addElement("Customer ID"); 
mainHVec.addElement("Order Date"); 
mainHVec.addElement("Invoice ID"); 
mainH Vec.addElement("Tax"); 
mainHVec.addElement("Total Due($)"); 
mainHVec.addElement("Status"); 
detailsHVec = new Vector(); 
detailsHVec.addElement("Item ID"); 
detailsH Vec.addElement("Desc"); 
detailsHVec.addElement(" Qty"); 
detailsHVec.addElement(" Unit Price"); 
detailsHVec.addElement(" Extended Price"); 
statusHVec = new Vector(); 
statusHVec.addElement("Status Date"); 
statusHVec.addElement( Status"); 
statusHVec.addElement("Remarks"); 


orderIDL = new JLabel("Order ID"); 
orderID znewJTextFielq(^ 55) 
IDateL - new JLabel("Low Date"); 
hDateL = new JLabel("Hıgh Date"); 
IDatePl = new JPanel(); 

hDatePl = new JPanel(); 

IDateDD = new JComboBox(); 
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IDateMMM = new JComboBox(); 


IDate Y Y = new JComboBox(); 
hDateDD = new JComboBox(); 
hDateMMM = new JComboBox(); 
hDate Y Y = new JComboBox(); 


for (int 1=1; 1<32; 1++) { 
IDateDD.addItem(Gjava.lang.String. valueOf(i)); 
hDateDD.addItem(java.lang.String.valueOf(1)); 
) 

for (int 1=0; 1< 20; i++) { 

IDateY Y .addItem(Java.lang.String.valueOf()); 
hDate Y Y .addItem(Java.lang.String.valueOf(1)); 
j 

for (int 120; i« months.length; i++) { 
IDateMMM.addItem(months[i]); 
hDateMMM.addItem(months[1]); 


} 

hDateDD.setSelectedIndex (30); 
hDateMMM..setSelectedIndex(1 1); 
hDateY Y .setSelectedIndex(19); 
IDatePl.add(IDateDD); 
IDatePl.add(IDateMMM); 
IDatePl.add(IDate Y Y); 
hDatePl.add(hDateDD); 
hDatePl.add(hDateMMM); 
hDatePl.add(hDateY Y); 


trackOrder = new JButton(" Track Order"); 
trackOrder.setForeground((java.awt.Color.red).darker()); 
String insl = "To track a single order, enter the OrderID " + 
"then press Track Order Button."; 
instLl = new JLabel (ins1); 
String ins2 = "Enter Low&Hish date ranges, clear OrderID, and " + 
"press Track Order to track orders within that date range."; 
instL2 = new JLabel (ins2); 
status = new JTextField("",20); 
status.setEditable(false); 
orderlDc = new JComboBox(); 


orderIDc.addItem(" "); 

gbConstraints.fill = GridBagConstraints.BOTH; 
ebConstraints.anchor=GndBagConstraints. NORTHWEST; 
addComponent(orderIDL ,0,0,1,1); 
addComponent(orderID ,0,1,1,1); 
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addComponent(IDateL — ,0,2,1,1); 
addComponent(IDatePl ,0,3,1,1); 
addComponent(hDateL _ ,0,4,1,1); 
addComponent(hDateP! ,0,5,1,1); 
addComponent(trackOrder, 1 ,0,2,1); 
addComponent(instL1 — ,1,2,4.1); 
addComponent(instL2 — .2,0,7,1); 
//3,0 - 6,0 reserved mainPl 

/7,0 _ reserved orderIDc,orderIDcL 
/18,0 -10,0 reserved statusPl 


addComponent(status ,11,0,7,1); 
set Visible(true); 


=o ao a a a Gum a a a «шә өше еше өше «Ап олт Oe Oe SS S22 2 2 SS «ше «ше еше «шә «шә «ж» «ше өне еже «шә «кә «ше өше «ке өше «к» «ж Sw we se SS ww we «шо «қ GER ee ee 


trackOrder.addActionListener(new ActionListener() 


public void actionPerformed(ActionEvent event) { 
try { 

status.setText(" Tracking Order.."); 
mainP] = = new JPanel(); 

orderIDcL = new JLabel("Select Order ID for more details"); 

lots.OrderMainInfoStruct [] orders; 

String |Date = java.lang.String.valueOf 
(IDateDD. getSelectedltem()) +"-"+ 
java.lang.String.valueOf 
(IDateMMM .getSelectedltem()) +"-"+ 
java.lang.String.valueOf 
(IDateY Y .setSelectedItem()); 

String hDate - java.lang.String. valueOf 
(hDateDD.getSelectedItem()) +" -"+ 
java.lang.String. valueOf 
(hDate MMM . getSelectedltem()) +"-"+ 
java.lang.String.valueOf 
(hDateY Y .getSelectedItem()); 

orders = mylotsMed.getOrderMainInfo( 

orderID.getText(), IDate, hDate); 

mainVec = new Vector(); 

Vector rowVec; 

orderIDc.removeAllItems(); 

for ( int 120; 1«orders.length; 1++) { 

orderIDc.addItem(orders[i].sOrderID); 

row Vec = new Vector(); 

row Vec.addElement(orders[i].sOrderID); 


to 
© 
lO 


row Vec.addElement(orders[i].sCustomerID); 

row Vec.addElement(orders[i].sOrderDateAndTime); 
row Vec.addElement(orders[i].sInvoiceID); 

row Vec.addElement(orders[i].s Tax); 

row Vec.addElement(orders[1i].sTotalDue); 

row Vec.addElement(orders[i].sStatus); 

main Vec.addElement(row Vec); 


V/for 
JTable jt = new JTable(mainVec,mainHVec); 
jt.setRowHeight(13); 


jt.setPreferredScrollable ViewportSize( new Dimension(400,30)); 
jsp = new JScrollPane(jt); 
//mainPl.add(jsp); 
addComponent(jsp  ,3,0,/,3); 
addComponent(orderIDc ,7,0,1,1); 
addComponent(orderIDcL,7,2,5,1); 
update UIQ); 
} 
catch (Exception ex) { 
status.setText(" Exception in getting states// " +ex); 


orderIDc.addActionListener(new ActionListener() 
| 
public void actionPerformed(ActionEvent event) { 
try { 
status.setText(" Tracking Order..”); 

statusPl = new JPanel(); 

Iots.StatusStruct[] states; 

states = mylotsMed.getStatus( 

java.lang.String.valueOf(orderIDc.getSelectedItem()) ); 

statusVec = new Vector(); 

Vector rowVec; 

for ( int 1=0; 1<states.length; i++) { 

row Vec = new Vector(); 

row Vec.addElement(states[i].sStatusDate); 

row Vec.addElement(states [1].sStatus); 

row Vec.addElement(states[1i].sRemarks); 

status Vec.addElement(row Vec); 

Шот 


JTable jt = new JTable(status Vec,statusHVec); 
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jt.setRowHeisht(13); 
jt.setPreferredScrollableViewportSize( new Dimension(400,100)); 
jsp = new JScrollPane(jt); 
addComponent(jsp ,9,0,7,3); 
updateUI(); 
} 
catch (Exception ex) { 
status.setText("Exception in Tracking order” +ex); 


\// constructor 
private void addComponent( Component c, int row, int column, int width, 
int height) { 

gbConstraints.gndx = column; 
gbConstraints.gridy = row; 
ebConstraints.gndwidth= width; 
gbConstraints.gndheight= height; 
gbLayout.setConstraints(c, gbConstraints); 
add(c); 

}//addComponent 

\//TrackOrderBean 


№: ВАГАМСЕВЕАМ 


//BalanceBean.java 

import java.awt.*; 

import java.util.*; 

import java.awt.event.*; 

import javax.swing.*; 

import java.lang.String; 

import org.omg.CosNaming.*; 

import org.omg.CORBA.*; 

public class BalanceBean extends JPanel ( 

private JPanel pl; 

private JLabel itemIDL, partNumberL, taxableltemL,salePnceL, 
unitOfSaleL, warehouseIDL, balanceL, 
reorderLevelL, reorderQtyL, separatorL; 

private JTextField 
itemDescreption, partNumber, taxableltem, 
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salePrice, unitOfSale, warehouseName, 
balance, reorderLevel, reorderQty, status; 

private JButton getBalanceb; 

private JComboBox warehouselD, ıtemID; 

private GridBagLayout ebLayout; 

private GridBagConstraints gbConstraints; 

private lots.balanceStruct balStruct; 

private lots.lotsMed mylotsMed; 

public BalanceBean(lots.lotsMed inMed) | 
mylotsMed= inMed; 
gbLayout = new GridBagLayout(); 
setLayout(gbLayout); 
ebConstraints = new GndBagConstraints(); 
itemIDL = new JLabel ("Item ID"); 
partNumberL = new JLabel ("Part No"); 
taxableItemL = new JLabel ("Taxable?"); 
salePriceL = new JLabel ("Sales Price $"); 
ос рака о И = пе Label Ty 
unitOfSaleL = new JLabel ("Unit of Sale”); 
warehouselDL = new JLabel ("Warehouse ID"); 
balanceL = new JLabel ("Balance"); 
reorderLevelL= new JLabel ("Reorder level"); 
reorderQtyL = new JLabel ("Reorder Qty"); 
itemDescreptionz new JTextField("",25); 
itemDescreption.setEditable(false); 
partNumber | -2 new JTextField("",15); 
partNumber.setEditable(false); 
taxableltem . 2 new JTextField(" ",1); 
taxableItem.setEditable(false); 
зајеРпсе — 2 new JTextField( ",12); 
salePrice.setEditable(false); 
unitOfSale = new JTextField(" ",2); 
unitOfSale.setEditable(false); 
warehouseName cz new JTextField("",25); 
warehouseName.setEditable(false); 
balance = new JTextField("",12); 
balance.setEditable(false); 
balance.setForeground(java.awt.Color.red); 
reorderLevel = new JTextField("" ,12); 
reorderLevel.setEditable(false); 
reorderQty = пем JTextField(””,12); 
reorderQty.setEditable(false); 
Status - new JTextField("",50); 
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warehouseID =new JComboBox(); 
warehouselD.addltem(" "); 
п | 
lots.IDsStruct[] warelDs; 
warelDs = mylotsMed.getWarelDs(); 
for (int 1=0; 1< warelDs.length; 1++) 
warehouseID.addItem(warelDs[i].sWareID); 
V/for 
} 


catch (Exception ex) { 
status.setText(" Could not construct the warelDs comboBox/ " +ex); 


} 
itemID = new JComboBox(); 
itemID.addltem(" "); 
цу { 
Iots.ItemIDsStruct[] itemIDs; 
itemIDs = mylotsMed.getltemIDs(); 
for (int 1=0; 1< ıtemIDs.length; 1++) { 
itemID.addItem(itemIDs[i].sItemID); 
V/for 
} 


catch (Exception ex) { 
Status.setText(Could not construct the itemIDs comboBox/ " +ex); 


} 
getBalanceb = new JButton("Get Balance"); 
getBalanceb.setForeground(java.awt.Color.red); 
getBalanceb.addActionListener(new ActionListener() 


| 


public void actionPerformed(ActionEvent event) { 
try { 
status.setText(" "); 
balStruct = mylotsMed.getBalance 
(java.lang.String. valueOf(itemID. getSelectedItem()), 
java.lang.String. valueOf(warehouselID.getSelectedItem())); 
warehouseID.setSelectedItem(balStruct.sWarehouseID); 
warehouseName.setText(balStruct.sWarehouseName); 
itemID.setSelectedItem(balStruct.sItemID); 
itemDescreption.setText(balStruct.sItemDescreption); 
partNumber.setText(balStruct.sPartNumber); 
taxableltem.setText(balStruct.sTaxableltem); 
salePrice.setText( 
java.lang.String.valueOf(balStruct.sSalePrice)); 
unitOfSale.setText(balStruct.sUnitOfSale); 
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balance.setText( 
java.lang.String. valueOf(balStruct.sBalance)); 
reorderLevel.setText( 
java.lang.String. valueOf(balStruct.sReorderLevel)); 
reorderQty.setText( 
java.lang.String. valueOf(balStruct.sReorderQty)); 
| 
catch (Exception ex) { 
status.setText("Exception getBalance: " +ex.toString()); 


| 
| 
| ) 
gbConstraints.fill= GridBagConstraints. NONE; 
gbConstraints.anchor=GndBagConstraints. NORTHWEST; 
addComponent(itemIDL,0,0,1,1); 
addComponent(itemID, 0,1,1,1); 
addComponent(warehouselDL,0,2,1,1); 
addComponent(warehouseID,0,3,1,1); 
addComponent(itemDescreption,1,0,2,1); 
addComponent(warehouseName,1,2,2,1); 
addComponent(partNumberL ,2,0,1,1); 
addComponent(partNumber ,2,1,1,1); 
addComponent(taxableltemL,2,2,1,1); 
addComponent(taxableltem ,2,3,1,1); 
addComponent(salePniceL ,3,0,1,1); 
addComponent(salePrice ,3,1,1,1); 
addComponent(unitOfSaleL,3,2,1,1); 
addComponent(unitOfSale ,3,3,1,1); 
addComponent(separatorL, 4,0,4, 1); 
addComponent(balanceL,5,0,1,1); 
addComponent(balance ,5,1,1,1); 
gbConstraints.fill = GndBagConstraints.BOTH; 
addComponent(getBalanceb,5,2,2,3); 
gbConstraints.fill = GndBagConstraints. NONE; 
addComponent(reorderLevelL,6,0,1,1); 
addComponent(reorderLevel ,6,1,1,1); 
addComponent(reorderQtyL ,7,0,1,1); 
addComponent(reorderQty ,7,1,1,1); 
addComponent(status,8,0,4, 1); 
set Visible(true); 
V// constructor 
private void add Component( Component c, int row, int column, int width, 
int height) { 
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ebConstraints.gridx = column; 
ebConstraints.gndy = row; 
gbConstraints.gndwidth= width; 
gbConstraints.gndheight= height; 
ebLayout.setConstraints(c, gbConstraints); 
add(c); 

V/addComponent 

} /ВаапсеВеап 


208 


LIST OF REFERENCES 


Akbay, M., Lewis, S., Design and Implementation of an Enterprise Information System 
Utililzing a Component Based Three-tier Client/Server Database System, 1999. 


Blaha, M., Premerlani, W., Object-Oriented Modeling and Design for Database 
Applications, Prentice Hall, 1998. 


Booch, G., Object-Oriented Analysis and Design with Applications, Second Edition, 
Addison-Wesley, 1994. 


Deitel, H., Deitel, P., Java How to Program, Second Edition, Prentice Hall, 1998. 


Emasn, R., Navathe, S., Fundamentals of Database Systems, Second Edition, Addison- 
Wesley, 1994. 


Hamilton, G., Cattell, R., Fisher, M., JDBC Database Acess with Java, Addison-Wesely, 
1997. 


Henning, M., Vinoski, S., Advanced CORBA Programming with C++, Addison-Wesely, 
1999. 


Hoffer, J., George, J., Valacich, S., Modern System Analysis and Design, Benjamin/ 
Cummings Publishing Company, Inc., 1996. 


Inprise, Gatekeeper Guide, Inprise Corporation, 1999. 


Kroenke, D., Database Processing Fundementals, Design, and Implementation, Sixth 
Edition, Prentice Hall, 1999. 


Lewis,G., Barber, S., Siegel, E., Programming with Java IDL, John Wiley and Sons, Inc., 
1998. 


Norman, W., What is XML, 1998. www.xml.com/pup/98/10/suide.html 


Nissen, M.E., Agent-Based Supply Chain Integration, Journal of Inform 7.:on Technology 
Management Special Issue on E-Commerce in Procurement and the Supply Chain 
(forthcoming 2000). 


Orfali, R., Harkey, D., Client/Server Programming with Java and CORBA, Second 
Edition, John Wiley and Sons, Inc., 1998. 


Slama, Dirk, Garbis, Jason, Russsell, Perry, Enterprise CORBA, Prentice Hall, 1999. 


209 


Taylor, A., JDBC Developer's Resource, Second Edition, Prentice Hall, 1999. 


Treese, G., WinField, Lawrence, C., Stewart, Designing Systems for Internet Commerce, 
Addison-Wesley, 1998. 


Umar, Amjad, Application (Re)engineering Building Web-based Applications and 
Dealing with Legacies, Prentice Hall, 1997. 


N 


INITIAL DISTRIBUTION LIST 


ІБЕГепсе Геспикаттишотпапоп Септег...................27..ӛ.ӛ........20..0..... 4 м2... 
8725 John J. Kingman Road, Ste 0944 
Fort Belvoir, VA 22060-6218 


О... 
Naval Postgraduate School 

411 Dyer Road 

Monterey, CA 93943-5101 


Prol Dame PDO Ode ISDE I a ao 
Naval Postgraduate School 
Monterey, CA 93943 


РтоГевог /атев Вге( Місһае! (Сойе СӚ/МНВ)........................................ө өзек нө. 
Naval Postgraduate School 
Monterey, CA 93943 


СО У ето Ари Югай ашны Ым н ы зды о eee 
Jordanian Air Force 

North Marka - Amman 

Jordan 


Ahmed Ali Falah Almandeel Оюотп 2... тен кн ннен кеннен кенен 
Alborge - Soof 

Jerash 

Jordan 


Computer Center Jordanian ATT FOrCE inicia mI S 
North Marka - Amman 
Jordan 


Chairman (6 908! S 2 eso нов ас ава шалыны с a ОИНАЕ 
Naval Postgraduate School 
Monterey, CA 93943 


69 мот / 


6/02 22527-200 NLE 






































































































































LÀ 
° 
=> = = 
е . 1. = » = 
- =» » ы = = > 
Еч s . ы == . 
—R—  UmÓÁÀ кн LI . . 7 . e. » б LJ Б sos .. - 
E --- 0 А . в - . L] ? e LINE CE E = . e 
——— = > M + .. ы .- mL T 
E " E в А О - ^ М ... . . О LIN EE oe ze ` = e. 
. E Я ~ ИЕ И и и = E -~ њ -- E “-. 2. Le e b A! 
ee - . = . * * О РЕКА E E ... н + > ` o. E eens . -. - А E LE 
. LI .. ГІ . ПИА L] * e . . For *- €. nm. - Se. ... o” ^ - 
А Ы б . П " А . . LI E " P a . o . С е P > rl ... e 
. . LM .. . А РА n . 2 - . ... СЕСЕ , . = . - .... БИ КО РТ Бч 
4 -.,,% . • б .. . .. . PS “ eee E С E . r e .. E .. . .. s. DO ^. . . 
А ~ E .. +. - ЫС E LP = E . . E Й 5 E - ° .. LIP 7 . е - ко - 
А .o . .. ° Ы E а x. А А А А " . . . .. Й - = . = " " » . А . ео « O ya СР * $9» LL =. - 
ПСИ ЧЕ сә сә О > е РА g . Г m А .. А ГЫ " . А " .-. й P E % >, e . Е О . . o e * IEEE IMP .. ». .ә 
o. ҺЫНЛЫ = МЕ. 9 "е “or o ы О m Ы = . .. б ae Б © «6 . a E " . О . . . ° > > > .. . . P CE ve LE 
. т O Beses . wie o. в, А . . с . LI "* . . А - . a. Se - Г б LJ ы M " „ә б - - ЖА. ББ 77" Б. ВЕ c= 
rm ө» Bhd d E E NEP М LI с . (a О .. О жә А . ГЕ) О LEES E se .. .. . . в А t " а Й . = О А oe . СКИ" a ad О = m " . 9 nn LE TL ..o . ba 
bea == Т ie EIE . *- s. Pos . E . .... ... P "m "P б ee « Ф RR .. . .. . б б Lr а. ег = m + - ғ.а ы ео о күүнүн 
LI LESE ; мов = ы ho ^ ... .. - E + [I . = . .“4.. on. .. " " . . .. . РУМ o . .. А ° РА P . .. O P .- . e». 
и Ы МС - 000800 05. дд Г ЛИ аа = жы. т .. = = . C A E M es . Py "un ~ в ou. - ^ . О . • е т. --6. о .. . 20 A “oo. | UL np - 
Ы . тюз ы Ж Ы - -. hd LI . =e - . А ЕИ . .. .. = “- = P . . 0 . = ee - . ^? - П Р . 2 ee . ome > о 
v. .. E . Ve E лы. == Ы ы Ld .. Ы ee ГЕС eee .. [PS . 00 . . . OE. . e. О . [EPI . МЕСІ Pr} Й P • =. - a - L] О . 7 LI . e. . . . е D LJ КГ EJ en” - РІ" m = == 9 - LI 
- - . .. ee. = . E E - о E E & == ы .. . В "m E . Ё ° .. В А ғ . T " . wis PI P А .... е . .. е + A И «о Pu 
- .. - . • .. . . е е eee . .n . ... . ы L] . ГЕС . . . LI re .. . Г “. . = ^ а .. б ee ee -* LJ е L] L] .. y - 0 0» 9*9» o-»' 99,5 *..» Hu . .-т- е... 
PI О E ы и r б С ы Lern . .. . a e > . С П E . .. ^ PT "n a К . ^ . . А LA n . o HJ S AA - a om 
son. М ." . . .. ы Ж.Ж. ee m ~ СЕС .. ЕКЫ РАСИ) . .. П О . . . ee Й • м, ... P - " . e E . е ee а > >= Pad . е. = mw yo u ee — » 
.. C Te СИ "P L А ~ . . Er А . P б L " " е . . E .. “ E О ee D ^ PI в E [IN . ILE . = = . - >ч „ӘҮ Күз 
P LI Б > э JL .. E А E .. B = =... ТЕ ... =. es E LE S; a " . 4 . LE" э ° | са . . ы КҮҮ ТИТУ “o ос =ә е a. 
.. .... Ten nam ee hu m mg А Б - Ы А ИГИ А a . " e... ... D E RES А б б А • a . А =e . * СТО AA rm er - 9 А 
= ~ т e -. Bees ... Ы E "a E .... ` LE "or . .. .. la E ...-. " .. . Р E . E А ae А А ЈЕ а а m a m ө эө “. . A , С“ РГ ГР ы mn >. 
o EL CL NE T = ыы ee АД, XP жеу "nn on . М .. 1%... - .. СИ ТСЕ " . . .. =. . = PLI E m O T. -a Ы БИЧЕ" - ° е . Сур . » mM ^" ^ 00. 
Ы • + . i to. x e... .. æ t. a sme E . С DINE LP . E . ы = РО . .. + . . E rm - eae . C e e.. >» АЕ У БУР 
.. С u. С РТ wee owe So. ... .. б . . e B .. СРЕ А e С = е EX = „ .. . = . . E А СР or "^" ee. ЕЈ > Le ° ө ~ 
. SI == om D ... В . Loma. e da A " ° = LEM PLZ .. СА . П - - М = . . б - ы AI Е °» С УЧ е 4 . СТР КАР съ хо 
y .. pop - = no . e+ an Ы Ы .. СЕА ОРИ . . А Б М А . O . ~ - - А E - РХ " А .. А .. . . С LL СЕТ ы a a -- © ттт 
„<-> - sow., Ж и rie А E E "ова тле = СА LE E Б » o. A - .. .. - . О on ^ . " Е . . Ls a . ИГИ .. . LI ~. mm n ” ә bat A na 1 
E тізі те аги еса ON w ao tu. Е HELP TE Ы = .... =» =. ©, . LL = E ... P . о "^re - . + :. • E М . LI LI LS e. «os = а . LIE 
а Ss А м! ne ME. ЕЗ порно в во О . .. . Е А оз . fa Й a ... y M О .. a О oe LIE ө LI LIS - = СЕ ....- "A. e ees ccm ew saa 
ре; A А Ша . >» LL] е Ы • . .. . A 7. О * . . E E б E ee on E ПЕС . . 4 . е LES [LEY - a оо " "99 e e e. 
= € E ~ P. E. ЕА Ы Ы Ы ES та Фе бе э эсе ө LI „mo. CE es . LUE TN = r ... LINT m . . - a -nn б P .. IRL PA ССРУ E c. 
= = FE КОНЕ 4 x .. s es LE E EE ... = = «ве љ а о no = . . E LX - E LET б П" E E E 5 cee м. о LIES * 29 ea А ч» E E LE 
А Е уа rk e а С ы И a te * oe "6 .- as .. . А ы " -— o» E А TEM А E ^ А А ТУРЧИН A - ie О s.t [ELT LUE SECUN EA A 
» a PNE 4 A, = ~ tJ А = ы ..... a . LI АК LI - . e . а СЕЈ . a - .. - + Ы б ° ГА ГЕ о И“ . a LJ 2 bd $ е әр а = AS a ТЕ 
25 ЗЕ Ы ТЕЗИ ты ae . Г PLE re “. Ы .. % 424. -.. Б e L] Pr} М LI 9 9 “" - z.. С LES - ... ~“ . . - . - - ..,„e LEE . . БЫ hd - Li LET - © o.o LE СЕИ] a= 9 9455-3 
A e us en P: a 244? с LJ . . ы . 0. зе LIE - - б О Б LI LE ung Ма ое. . . € . . ee . .... РГА - P . „ЖУ ... ы .. . СТ = *"—-.. w «= 
= А ar ee Beer ans Te A Ey еы СЕ О ЖИ ЫЕ" E с а 5 . e. o ©.. a Я А Ы „ “~ . ... a. Т” LE - 7. LINE РР • СР У A е% ЈА Se тик ви 
И pes td ae en = Ls . Ы LPS - b E Аға - - Ы . m L] LI . . . „= а .. . О ва .. aa LE а А ..: I е ae LE 205 -ə. om a LER T era 
Od А И ыға алың а НИСИ "tun >. LE" "NN С -. е “ж... ... ... LL ° Ғы > EM СТРМА . H m . e.: c aora o, DA A ds Y о A 
NER Reg А Ps A M © wane . . LI EI] 60 1 4. . LJ LI a - . LJ = - Г] . . . P .. • . . L] . " . ... .. Led » Ы т . ы” ^ LI LJ 
= 4 рей ал MEA El 2 A =. a ғ”... .. e . e + LEES О А [ELT ^ E .* - D * n . E "I LE б О . .. E „a ... .“.. - , eoa omeo a u a e  » "apt "9 aW gi 
E er т. б з желм, ы 12 -=. - Б . . СЕЗ ELLE A O a ar *.9 « • = "e ГЕС *a* e o СУ = T1 =. • м О .. "a > ae L^ "x А n . E t... e СЕЈ P - 7 eam . ТҰТТЫ 
к PC АА Fir Ans ER > "lo Bb o mms, pé ELA "rar .@ ES -ea =. П б -- = СС И" О LE . өе ә А LI РП Ж Й .. m P P P " • . m • amen ye a we Sn... УЧА LP VERE Pm 
А ~ paige К ЛО кй. CN EL DINE XD . Ы - LES ДІ) .. E E PN Д * ec * . . E Б rs . " .. - > LIE = о O е E Lom. 
ee Re Fats С У УГАОНЕ = Е .. E E . СИ ст ..... А ОДА Р . m . .- " L] . . . = - ITI . P [] Ca LJ .. . . » = лач ӘӨ © ът 2 КЕ УЗ РТ . 
р А В ES а P ae СИНГ .- sms .. "Em А . .. . Й А Е в а ғ . .. Ы . .. e. e. . aoa . О ылы,” . 5 . -e- - ә “ е. Y ne 
ee ~. "oros - ** 9 e * gae e hdc ЕГ . = e E ы LI A uo. o ... a . " * ess 5 A E no . . «lao g T Lm e . ee О . ..% a ar, .. a А m . E . е О A + - de as е осечо-4 о, с 
ее. hd na БАК ТЕОНА О ша та .* ¿o Cr ... О .... D СИМ .. Й П • eee ..... e$ © Я . op e 0 @ce e .. a .. . % ам e . вага А re ГЕ е 4 . - . LN = Sen Om . 9 9 - 94. 
Ы а OA сма zn... E ... ЫЫ .. А 5 К - ЕКТ Ы > О ` ~ С о СИР a 1 ы a " . . СИМ . ee .. a . *° ез оше E LI ^ e. ^ com ..os ^" - -2 
Б LLL" E E - m Pon e Ras ПСИ РИМ ^ " = «ome .. . "n PH а” - te =. ... ae - - . E А . С - . . "T . "e . wr o P е P ~ LJ a= belli d еі ® © 
M10 иди + br ANLE Y) 5979 LIE Mm -. A AA ву E Е " ru П ы СИГ "+" E = » ho. E СИ А Ы = .. E LED LI M КАСОС S Ы Си e — -- еа no. 6 <> «ae Я 
een Pas ETT олын, ы p 2 ed нж жеге Li .. ^tt a, ... МЕРЕ E Pao .. E Lm >Я ase “sun. О . E A А . СРЕ . E О ПР ** e" «а г. Сит. ee “8 tow > . 
BAR Cn кес Pi: ew АЈ =. то... Е potu. .. LI . . Б m--* LI .. СМ .. . - Ld .. (ТИРА . Б . . . . w ы ... ee - .. .... ~- . . ~ oa 9. ы bass b. 
г ~. - А HJ ..- LIS Ln DIEM ВР LIMES M . . . .. "СИТ - = . .. .. .. P P „а. - Фо © . " - m - -- * 4 *.- - = - = PE 1 
С "OMEN a da Мы, ЕМА g EN САТА AT Ы LI LE P ree . .. . LE .. EST La " ees . = О m . х б БЫ 2 . . мл. IK k е еее Ls © - 2. 
ъв ооа Ty ed кет... ED L] О ИИ ".* — se ve . LP СИП А ГЕЯ . ea 1 y ° tye OT " П r " ee E РС А ... aes ГЕ" ^- -e e... . ^ 9. - 9 "ww * 9*9. 29 w.- 
ER НЕМА See LE T "999 e... DEI СА А РАТ o tan, A Л ДҮК . - 200% = аа .. LETT U * . LI . * ws e . ж = Ld LJ - . же . TO ИРА СЕТ ~a - <- ы Гра 
ere o ЈЕ. РА о ты "Ere" ве s -“..-, b a . О О E А E a Ж LEM PT .. . P a. PLI DIES MX NL >> 
ar d 088 обаш оа оь . 00%. СИ СПИСУ РОКУ neo Ber о LET р m А са” ГЕЈ LJ ^ * «© we e ... P . ~ m О ~“ ~ Ь оо и У TE ОР 709 -—-  - АТ --.. 
КЕ ране пад прија а LI ‘i LY RET Pocos CINCO S LO E us . > б eee .. ТҮЗ © ~ . ° › ГЕ Sema e. Ы e . .. 20 0 Cem 28.5. нет ee 
Se ee en рын = CITO E Ы 5... 6. % ..е .. ... ШР .... А TE WM" E . ЧИН A - WEET - Б a. . - ° 5° .* PERSA u a шры "^ ото 
ьа b ы | AAA О С ЕЕ TP" IW Т АГА a "erc а А . = . " " . а ыла а A nee А E MA > av^ МА И ОД ОР r 7 
ee еее чи LE, se >> S d ыы LI a, AA E A .` ГЕ 6. s a ЕА “on. „m m Е ^ = “= A ЕЯ раза .. a. > o -e LE "m rias S AS т А > > ЖРТ НҮ Ра 
РА abies Ы ы ы “oe anu m EUN, Entum na e 1,0. КЕСА . "*o eee . .. .. . . " " Re», . * Ao Ы . . . e on А T . LI Ы 7 “. we of .. ea .. LI -89 B LEE > . A TEE rn LE Er 
Е aa i^ aah a ын CONCA A TS LUN 65 en... €. . СЕ E .. " .. В Я қ. Б FA T A - LE 9. 0... . * > T a o КИ A e ГУЧ За" LEN " ee. LN PIPER - 
е pie Li FT .. А Perr . .. 0.0. . А оа o.» we UL PP a СЕ . . yr Ar .. СР as . .. Й ao TO ЫЛ ү E . .. E LC LÀ 8 ој I er et 
rm E .. ge ТО А Per o a. A .. oreo sw 9^ mae ... D ИСТИ * ы a ”. . - L ace Ы "*-:* € oo LI б б . L] О “о 999 ay LIE] LJ КЕ 7 rl "6$ @ bibentes L.X. E ТҮ ые LE] 
КОРЕН сз ды = . e к A К e RET ES DAMIEN D LIT SP on CIELO Pr Е А TEN P. e. > С . CUP ^ Ға FR аф» оов - On nt an 
2 Fr E Ы E . . LP en .... fw en "ese , eae - ЈЕР "n • E ЧУ А . о . л Т . ° Ы E a - - ... 24: Ф%”егаца е- eee те ... = . . er.c wow oe .- 99. 
A AS "®% өң e. aro n o. »..» LETS II ee "S " Li 0 .. 3 A . P ч " . ъ. ө ^ Pr} . ... : © ae О А a. . ea. ГҮ . *Re E ы ә СКИ . РЈ а ЕР - 
рудыц ey ИЛ -- se, ым» ақын, лет LT Et E ПКУ . oos s .. .-. P] E Don О А . e - СИА LES .. ГҮ LI LEE т ооо Lo Ы „un ! „u. (РРА мелочь 
ate = Do ИТ И а. Ld .. о a. С =. А СРИ [LES oe ome " na AS - E А . - LI Фа г Ж LIP . . “ I .. - . P [EN PH E *& s o = сео = с" 
E A ЕРЕ A E .. .. А өлі 7а: ”. so СИ ERA С nu .- . ас ә = B "955 à s e mae P PT 002 ае ә LIS NT . E IO — Lo. оо еве = оар „л 
АКА ... .. MA OOO ery [^ . P E ““ mo. . Г. о ... Er A . = E oe “а О РГУ А om. . . • . - 2 = ee - C e a "2 on -втел е , A г 
Ф Ач »е,6 е... DILE CUN РРА а НА .. “а .. РА А M “ “ .-.. А . "PI А Си" P ee wa a ШЕ ом о д 4. ad ОКА УР To n.oo 
A m ta et .-... ТАГИ s О . e... „tm M ° a P . e ... ET А БСУ E ... LL ee . ee ~ o œ~ uu, ОКО РГ ут“ у ТУ ТУР ние ЛІ 
Pini cc .-.-...-7; СИ" .“ > РИМ nm .» ... .. М . - . г. Ы * о ^". aa . «a . e .. T . ТЕК ... . ...... . ° .... л > = = ELTE “= an m ТКТ 
A Рузи ык И УМ БЕН ЗА ЈЕ ТУ ТРАЈАНА H о. DY. . LI . .. . Pr} P aes . " 5. КЕС LI ^ $25 E .. a . ul mom Ы ТТ er? dude EIN ч 4- “““ өз» 
ao mele JD . а O E E * esc * woso’ „Tele a .. ~ P" А . в иене та CE C" LJ JL" n T f ain irás БАЗУ 
"c. aaa E Ы БА ын. A x mare E Й СТИМ - . + eee - u. во а а ЕСА Ы РЕ “. ^ PL) б ee . Ф- • vo -— Д Mie Ede LR E, E о о no осв 
RA ы ыд) an СУД LION E LED oo. т = 660 ооо . . О LUN LI . о... ~ ьо O P .. М ... 2... » - =~ ... . nn ae У Lid a 
= Ф A id * ФР ... "^ "* ene ы .0 . .. ГА е = С" LEE II m . .. . А . Li me њо у teoa [TU a . ~ Ma JE I ЕТІНЕ ых p ымы "o-9 «9m e... 
. giu: Ba DL BE Er ~ А Yn Ж ыы ТІ Че асы *? 9 «9 LEN ИССИ . . . - LI L] РА ~ . mi .. - . ылғы. - o naa PW . EE 9? /—" 49 9.9. nd г LIE 3 КР“ 
E . On И s NL XEM dU. DE i LI mn Ы . а СЕ миа "бы “ .. . LENT . o. РА "E "m ә a. . a? per СЕ 9e 9 om JL. e" т M 
er уу Бе ъа кы тэ .. et .. бтз. о әдат 5а. ао. e РРР Зарнена er ... Fi CT eerte = A EA Parte a as AN Cre ES * А E ~ РЕ ы ~ ы • е. 4 е е = ee nb A Бо, слао о о 0.0 am e bd Б. 
= А aa dE ну ...... а-а =. г АДГУУС o A 6 LETS "D E LONE DC So ege "T .. А ea "m .. . q. °. в % % Фор в * $9. e» $m poo goa ICO ATA ара., => пр 
Sa = ie ao Ји A БКЈ E ... АЧС МС ТРКУ 6 о "M m e e. > " FS А РТ ^ 2 " a u. 0. ... IA E "Т е Фое о ә е өс 2. Ур и 
wu “m me an Re b LS "ru Mon esae ECL RR АСИ ЈА ч Өе Са се ө D СИН .. . . . РРА "ә +. - ® . Far Е "ner РИС РА НАД РТ АДИ У © т НОД пад Чу Lr e 
А PO ee See хак ...0%0%%08.0 a. Mn o seno В . * .%% фа ар он А mI D LL ЛҮҮ" A ED . e *"» 9*««.99« LS "ДУ А Г E - РА men ЛЕТ T 
e” P р ығы LED СА .. О РАГИ РРА А toa .. ГИ" А . . - - - Г . ane - LJ - ы Ld . LEAST о.о 40е. ое 9-9 — ЖҮЛ СТЕ Тј LU 
A оњ 00. ee ee a en baat es поа қ ee ong, БЕР - mas Й ae ans = o "T "Red ri a "TT * es ACE EH СЫ А AR RC d 99m f sen m un pP ы: 
| an PA pi ДА TASA ORCI E HEU LUN Ра h а Гед „> „eds, at a ИТ р [17 ol “ne. m... y . A . РО . L] . . rn А are a А = РА a we o JN © ва dd *» Ф * ^... [X 213 und E Pur СКОР кт“ 
А "ym A ИРА А ...-. ұйы Ырысы ЖОС E ел в “.. .. ылы % os о 500 ое ы “ 2 va - ror P" 9 9 560004, , L ... œ ARA ә Lr JP "99 со ~; 
mk z = EN ee РА a 99. а ТОРИ te ~ ET о. ъа СРЕ РЕР E A e... .. . om u nn Ы ПИР И 7 аъ медији ы m * 4o ados 
ven P .. 2 је Ur er T T E LE TUI 0 o ПИТИ "А " LT . a De tees LI LET > "ИГРИ LI LAC * . = =>» СХ 2 æ .. -- үа СЕ“ ndi и“ > у ххх L 
ТИ И УРАН aed ДЕ С ИО T ae, Lo ee) РАВУ * ~ E . .. te LT дабу, А • А ЕНИС rer S [em x A МИА ДЕ ЈА oret АИ И ЕУР и Х-Р 
= = p m wu ~ ICC OO ЧИ РМ ITE (ТА ЖТА ТТЕРІ СИА T Uno . - . e .. ы • ы Sa. e LI . тайы ^ ТЕО ЧУ ~ s o apa a О ET LUE 
Д Д тик У A Y "зө А RETE E РИТА * ^. Lun « .. ..- ~ = a Жағы A E E T - 09-4. t - PINO T а en Ld iP эв “En = = © 
ern gas И ЕН ER СУ DIU E "gis . . г. Т; ЕРЛІ ар” me" А СУ .... ou. .. * 9 «4^5 we, Ра Пери 
=e q e E are E . - . . . ** " 94 - е) o . . . . i" d СИ) $ = о . Ll E КҮ ЕТЕР Бч УГЗ .. ығы СТР 
Fs 2i pitis a e А -— 9.99 c9 a. . um .. ac -. e" LN РУ" = Р" 22 9:9 9 % ө о.4 кес 6.е а, өм Малы, ung ie AAA T AT САД 258 
ОЕ ИТГ Ач E = wen . 4 9 - . T М ~ LES L БЕ" ДЧ ~ а8 аа Ф- се ae А РА Lll dial. PP ә ton “ee = 2224 £6252 ~~ =e =... 
penis: "® эз з э» „ фо» „ Б I = «ee . % . P LEM т е LL “n .. a LI Ж "-9 $ La, пи * "ә о», . ЕСЕГЕ жү Ж => о... .- pP > + - ест Да ТТ 
OSA 2... c, 3 = А = Я А ... . О ... . . . sv. AS P О ни o. LA AA . . Ф ал«.Ағаее ee} de Г P u... 
ъл УР M M *? * 9e $8 » * s а B mu . . - . . a ‘en ә о " ТТІ! . p е2 кат a - M EP ns BTL IL узе КАСОС ТУ у - 99 uL Т “e 
Әлтай ~» P P МГ e VY» А • + % . A а „ ® .. -. во ао 9а 4» ,.2,. ~ pU EIE LS MP б од ТД ни nam P 
М Re =. Ф Зоо ова .% . u. 00m g> ССР ~ las "S .. СИМ ™ ee АД 0, LEN LI "Uo -- a > 9a" — $5 m aps. t usen od eet 
ee o tere ee whe gm IT ЛАН z a. * ^ 9 А nr. tes = s CT 9 9 o a, AA Leo muss. a чует = 
. Eres A PE е ьа CE = LC БЕЯ С . • e ү" HANS vu c. .. LE TT > ob e.a. —— d 2^] - ЕЕ” йа най ДЫ cot a! has que 
wm аа. LIPPE S ... А a . е „~ . “%... LI EI my - LE L^ LEN E) en @e ANT db. Hm . ТА ДР BE LION 
У ои RPh © wot ae AN БКТ ПРЕ LEE XU" u 2 qe... AAA ES o ello, ыыы ЖЕУ ЛҮҮ" . . оте in tk a ны жа - 
ОРИ "E E TT А СИН АГА А T M . ~ Ре E „ + mc" a ы Ы О = ee oo алалық Т МУ ра зли аа оо ә о ард 
2 D POLL мыт . & 939 $6 . w E = Ы * оз ое & [2 «= a CTT" LET ES MALIN TEN аны E ER n seag bina IR фе a 
ОР УРА TP ree . % 4.74 «а% .. T ТТ МИА a • ES ~ P "m LLL LPS РСА ~. АЈ 0-20 AS LI NM Nn ји "У e 
*- 7€ ТЕРІ wee q. a. A .~. en Т E е o Min: Реле LM ТТР ... ОКА „ИМИ мыла А ыг now 
"a е о . nr ыыы ы ТЕ РР “.. Ре LE r а ^ * — v. a ~. E е ә о-ы -ғ2.-е «әзәмее КАО ХИ ых 
...5 о Ко © s 4 LPT > гь .. ...: TT TA г с... РУ .. = *°* а,ә . б . ~ P EJ ^ е . .c $ a m LI йн” ылы, Жыны T md. | ДАХ До т = ч БАХ 
КУТРЕ А АПК З аот а СИ ~ И E Y" ~ - Lei гг RE NP E ө v e м M k а г А OY ten дь, Peli disi d 
БЕ ТЯ ИТО = 0 " SS “mee [TI LLL .p. sm ү . ғ. °з оз ТА . ағ. А ое = 4 У “> * A" 4. 999.0 С 754 р ча “У Фе => 
АРРА "m i EL LL pe SR Ин ` • а О у AAA 4 4..%ы, , t о оо о - o -— мїм ны К Pret 
Оч}. „ооң ТТ „РЕЛӘ L] ee . РУТ - EP wf . P и КУ У . s. E p М. AAA A РРА 9 9.95 vu совага се оа 
ау д аге м ~ та пе "m P “an mn. ИЕ РО u Am, а оа уға Майы у 
CHE S к HIT D ^ ЕМ ЕС . “ М “ а. .8а, ae PI 90 02 6.2.24 2% ЭСЕТ ДАРТ би А алыр ys мб, ыс АТ 
КК ~ et @ АТИ % аФебөз to > Le] ^ a9 С EJ NELLE! TED P LET A A зе .. ОР) E ®Ф Pm m ј LET] 5 "A. Ll T 94.997 qun 
+ .. Ы o... [Te . > "TIPS eye Lr] ° .. БЕТТІ ... ~љ = РИСТЕ E E ы 9.29 -9 um af de ај Pm 
з 0.0 II AA .. LIT A „ E ... Lr . 9-95. ... КУГ DINI rr" " те: . Б 9 o N ЧАР 
e... ne cate .., > - со А eo m = СИТ ГРИМ А Cue de [LI в ы wee .e “ui sun ch њи dt. Eve А У АРА је 
A MONITOR TE АЫ RN К е оова а в“. A EI ДЕЙГЕ e О ... СГ С "^^ а пуно ae dL IA 
[ELLO ме. AL =. 91.9458, 6 . О РИС A .. ТЕС,” aot O, p, LN © - * 5,028 4, эе - ear . о е М ЕТ sid dba dai эы. ~ ~ s о == бе ы ho 
[PN a IL LSU de РРА D A m м оф о а ` LI ... [LIVE Te) e. ¿e ~ Lnd  ө% „ эмее La dc bm ad JE у с о % Ре oda 
“ur 3 I IT IT во 7" gabe "u". „а = *. 00 of >” . ы” егің yi ol ALT) . С зо Ме” ^ ws e Lr N DAA з. ји ДЕ 7 A кү 
... E тү $4 va ы ... ы а Jc Lt LAT M "n m -— Ф о=» = уља | ен ДЕ 
РРА me ee ооо m. = A “Ур ee г" 
x KE А ОЈ DD. Neen 2 СРИ P" е. ap al ЧРМ ЗА КУН „мл d . еөз = 
LoT T TM ee mm оо р КЕ еро а LE NE" «0.2 me Ы ҚЫ амы e cn ы О nn: © 0m a4 
e. TET 4. “ы... te КОЛЕ >. > e. P AS LL ILI то: 4959 86 есет ө Мы» С Lan E T ДЈ Т 
m ... . ~ LI 6. ~ . ITEM SI Lr IT МАА ТРЕ ју а E 
> ~ .. .s m "Tt A Ме, veo С АТ TT БУКА КУ У је Linde cod E «A he А и M Т 
2s 24 = е m PT EU" А „о ө ў "ul m " - bad lll ge LIA о У T ^ .... ПАДА е тете түн ^ 9 9 e «ЖІ. 
peck = Ar РОЗА e РРА am А . | n RT Bl NEP m bh ace урин а 77 “Ут MILI E ыла ы Т? 
= ES sas ЕТЕ Fan ee aa © э a. A " E " ИЕСИ туче “Am. а и E T јин | 
НЕМАТ ГГ T ES ӨР қ” o X д, Li К A A E а н УРЕ и ја уба ee Ы e МЕ ^ 
d © shes atte 2 4.2. Й Ч асаа ьан ао E „ә ЕЕ ШМ "ыл мн ыыы О ем, LI: S БОНУСУ иу 
А] E 5 МЕТІ AA e... m AN A СУ 2. НИР, л ЖЕ РИ қайы ЗОРА Учи ране А ЈУ tee nm 
АСК м 0.00 зе ЈЕ Alias ar FE rer to ик И ОЕТ ДАР о ОР ври А Мале очи да а У ЧТР А-ы "5 6 о mw ~ 2 
I у рө... МР РЕМ e е-е en ПСВ pr. . Ss. МЕ ENT ue 2 que a ГГ A O as o P (и _ ДРЕ“ у А de Ды „з “Жазылу, 
= Е а de .. ж С и сре» “a. . P Ie ws 20. ut o, СКЕ НИСУ У ЕТЫ ыы Pa 200% aq moome ом о о Y ЧА А ЈРЗ pertes и САРЕ a ове аи веће ла ма 
ek. “es m 010 те EPOR и MS A НЫ de um Ee e ү II AS *- офу ** -* 9. — 9 ^... mal Pes ыма "ТТК и ҚАР Ч 
AN APA ПОРТИТ Си " te . № tp LE" ПОР ОМА .. А ЛОИ СТИГ И”? Ш.Т” ТЈ руте Түү] ДА 2 Ы КА У е4 пе — 92. Ii d 
ГЕУ ГУ ПРИ ТИМ PT? TT . [IIT ^ 9)^8 * €* s. — vu. PI" MEC tA rr мев С] Li * mo Аы, Ж”, АЕ ЫП adis LE di о и ~ = mn. A ЕТ me 
4» e^» no Te А M ^ » sla ва № ТУХ LU b IM MC ~ o o ur T ПАЧ er TR р RAR hadas C Ire a н Rec At... А am 
AA .... УУ TTE си Г LM es „ү н Ро“ БИГ TN *99-9 99 .. o CAS Ре а РОК > A e Eo аи <->. or. 
САТА СОЕ РТА LLL 4 PLNS эу > ГЈ 8 428. ., PA TA - и МТС КР ад ы ТД Г Мари a e 
Е 4.4.4.» „ен о 0 II e. eee "TM P . . 4“ “ ә aogas, о ЖТТ ы. * «eb T eo 4. oap АТИ. ТА uw 200 4-9 esque У КЕ У и Де Ра ве а о 
А XT Боба us PEN | 10 ог IM TO TERT nc" y EMT ate me > > "L ro «e LAMP TIC ee n EI. ee ED er ne T => 9 ~ bc in her Ld ју 
а т СРР СРЕ PIN" m ote ot ot РІС TS MTM а ET) ETA " la о О ТТ AA Сора ДАЈ а. АИ у о ПИК РА р Дс зн рна Т Ode aum. 
E et. A AA АКТ И ВАР T .~ NP МИР и re Т • 5 асбачеа ће ве • ~ Б LIN ETE TS ај а а > о 
DT “nn А ...o ea "m ТЕС" e o. ъ„ азы T E TOT epre AI I АВИ А СА ТОРУ РА 
E .. 5 [TS BAIT 0 % аа КАКО ДИ ТОРЕ, ТИ ыы 
^. a tun в НОС РА T ИСТ MA AA A / 
Y ET Сит E ь 6, 
Би ON A Ни = 





о ыы + ae m 
СУ МО УК У“ У РАС а 
«9 „9.010.009. Ы bd a Ч T 9 uns. 
LE ТЕГ ^s 
*à*e Re A, os. чө, (CE0 TS we. aa 
Г] “4... ALS ul st... ы 
БЕИ ОГ СОЧИ 










































: оь. 
ја tad on Рувума beein ін, лл од en ғ.с... 
Ga war o me DT ыб ОК ХР "а 29. O's ређа а 6. 7 9 rr Зада А iar једва 
1 => D ы ы Ма ЖАЛТ ЖТ ыма АЛЕ У] и іа е brine ar en. P. ae 
^4 MS Raus fa. %4-2- оў E " ГЕЯ lodo Te E ХААРА Данко 
DLP eu 4 ОТА СИА M" rre .. UIT MUN LIA "4 9 «б LIU о i Dae MM 
ТҮГІ" ry Lm УРА IT Qas sto ve алата» 2 9 49.5. WA 9 ur Pete. o es => - МАХА“ "У bem іл не eek ne 
. AA MAT TN T n] ОКА ИСА [IL Lr] LI ле TT ло E СИР Em . и ји - 
Бор АҚЫ ЕТІК реа 4% 0:23 а ЧҮ E = A М2 * МИ) LL rU оче ђе , “а en» Мр пређе Видете ier 
LM ара а da “0.00 ОИ У И : .. ГИ ү q. = Шы АЛЫН ҚҰСУ жаға” ымы” и Зе 
» уер > РИА 4 ate a OL E ыы |. ML ne A ДО er и ИЦ ins А а ДР УЗ ЧИ 
о 4 , " un y ATA К a, - .. © „К е E Jm - . С У о ЛА OR =i o so. mep s oe 
Ме pt Lom g ЫН ia NN И A P 5 [M 9 liz . eya „ыта On ¿om A AT a er 
ТЕР "P E М ror n ATTN "m ea $9 — o» Ы ULL TY ем a m и Кра ni -pona 
M 44, зәее-е)? оде ө » 0.00 M м ыа РА Ри РА РУТ $ 9.4. nud MA EL Pte Eben 
ОЕ s ОИ“ ЧИ > о о. 40.6 АО * eb me Mi E "ewm. ta 4 0, m м. Мба а ТУ? 
I] ОСУ ТІКТІ Peba LAT T E "III MI тун tA 2. om б . ОЈ РЕМС У Гер Де ~ Со Фег- е; 
rer an anne БОИСИ РУДА па OE LI TE MTS AO e ыла ақ, д рео уь M > 
A РУТ РИТУ LN 4“. ЕТЕ “ ғ. E TA М ATA &m € А ЕМ ДУ и 
^ А * a^ et De Te MS AAA #Т^“ ое a боль үр. ке И ЈИ У ТОКУ ОР РА we ae 
ГР de РЯ У СРИ ИУ л e eae С КР LIED AA AT У 
- .. Р ГРУ ТРІО Тег А eý oe .9 \ * LII M © dl ot td 99 Aw Sean nu DV Am 
wee oy Ше, “.. “ТО AL IA T LL «© LI LINE" ДИУ 24 + ЖТ 2s5** в Оља. и, САМ АН Х 7 
ЫЫ ее * *« es." oted Gee КТТ: ГАР СОЈА р "ТИТ > hdd. ll P MP wm u fae о. Ip L^ [IAE TT RT dia] ya Б А54 
КЕГЕТИ ЕТ: a r e dS NELLE Pct = е ТА ӘСТЕ ЛИК у ~ 139 „ы ~ Ту. 
PU e AT МЫ CA ye NE A ы ДАН ee дода Да А У ЈУРИ 
ТІ “orte UN weee "n AS S E T БИК БУА A AA m ДРИ һе сірі у Ta 
А ТУАЛЕТ ы —9— wt «S E "amm ылы Чт T 1%) 29.0. ҮН ip BL Ir 
КРИ P e ГР m" me - n vL ESL E o oe li О rerit 
“10 M .. СПИСУ ма ЗЕР e. је ИЕ “ум ыны ДАТИ ТИ 2 = Гађа В de Da a 
mn. ow c We реч“ T “58 Fe terme ve “Vid ree ue e РАДУ у т АСС у 
и Saec $ A AA Ш.Ж LES о toT а РЕ БЕКЕ АДД РР ар аи 
Ги NS E PA et db ho gen bodies С Ыы А De re EVE лл А.» И. Уез 
ОВО“ > M СОКО У 4,2... 4. 07. . А УУ rr МАЛИ — то > ultr eie I its малы 
5 AS 445 Ф СЕКА УУ А 6 Ion С ПРО A LAU nn ПЫЛАУ И И 25 таз еа, 
ran МА ПИСТИ Уа м ow ма. чо he e. a РГ) ° б 1 A T $9549 4 o AS МАКАР СУ КИ ДР А 
мылы ЫИ Фо о о чето Фе о Жы ЛИ ЧТ УРУК et _ ef A AS Б EU ~ * ДЕН > и“ =>. 
о И УРА m: А Ру“ НИ mE [LI ТИ УУ pa We ЕЗ eee a a, IU A a 
СР ДИ ИТ И er e er LNSCR FEL PP e бл о И АВИ > 7) А A ad de ds MAMAS КГ УУ f AE и rhe тч Ы» anne So 
ПЕТИТЕ ТАИ as x uL T TP СЕ ie O „үе ove А ҮК ОДА her, e T o (| а На соль ьс 
be 1049 1. 22.) опевао ee 4 Ma 00% y eya LI ... nn dede MEL ИЗ ТИ ee ee РОКУ) МА a Вен 
АИ Sem УМ TS "IPSOS = = АЈС и ma 95 8 %%206-2... peu nt onde AI | а E 
2Өл Фға mem +’ с L Lu LN 1.» МА О О УН ДУО La hers br И у АЈ Ft een - 
ОИ Ри ОР ES U И РА А! A = TIT Lus I Sr WR ess > pa $ Mo LI 
% 4... 4% АТ, *24 М .. " И x > - aqu r и о О ТУ У Tren ms e МА а a S ns” Ч 
Ь 64 49 9 42 Я 4 с » € m ~ - аА ДР гче NT УМ УСТА ТУ ~ = RA. ll ә Le "e и he. 
МУ И РА u. С teed to У LEE AA er pda Mr E en T = 
ПА es ме Er > of % d dh es о ея 9 ll id дар кыы. > Li. “У Бен фи nn zen. 
го Е уни У ТА m ЖЕСТ TT 0 AS Er чу во а У 9 e БД = - 
IA a semie б ГИСАС I me ~ ае E ош а Bun а de ы] ae un 
> LI] E L] s .. 4 БД ATA 774 М” Г .. ~ LT Maced . - М ~ 
0 “Sar O үз m ы” К ы e a e 4s ee ee ОР were E «іа ғ.” ћи об а кезіккенде en ann 
BLISS "AP LP pre ` E TI D hm m0 5. 09 4*i- «^ov. e А a alit чэ" Дреа ое 
wre .. тез 47% we s ГР tr " FX ~ m» .ə y ¿e (ГР $ ГТ т - ~. -% Ко Арабы ae A Ч 
АД ЫЛЕ С ШК PT wm T a dores Lec sto IS nt м к we ng 
ОГИ ГР АД Luk А АСТА ТЯ ves A TEA o e anor -— 9 ** «» AE E «ne аге т Раны Ml, ‘ot Ses Р 
ВАСИН Иен ые ЫДАН Талы и ~ | Е e E y .. ғ 2... 49% -ч4 9% Vl T Lt ТҮ 
ne ча TN A, - A M Kex aL T ~ E zz МЕЈ И ne OR АА ы 
ALLE ТВОРЕ еб vibe СР РУТ = М PN we Ы + LLLI VIS дыз erg 
б 1 TIA . en [1 ~ e TTE D * gee Фо se 
. MULT (ТА P m E . г ips Зе 
мы” ... ы, 90 т DT 195 
А СЕ ТЯ е 








